3 Replies Latest reply on Mar 16, 2017 10:43 AM by hchiorean

    ReferentialIntegrityException after updating to modeshape 5.3.0

    prinzs

      Hi,

       

      after updating from modeshape 4.6.2 to 5.3.0 we ran into the following problem:

       

      When trying to delete a file node, we get the following error:

       

      org.modeshape.jcr.cache.ReferentialIntegrityException: Cannot remove some nodes because they are still strongly referred by existing nodes: {/{http://www.jcp.org/jcr/1.0}system/{http://www.jcp.org/jcr/1.0}versionStorage/{}53/{}63/{}2f/{}53632fb320c5312a4f98cfea0221d86bab739ec1=[/{http://www.jcp.org/jcr/1.0}system/{http://www.jcp.org/jcr/1.0}versionStorage/{}ef/{}d1/{}ce/{}efd1ce92b033299879aa009fabc40f49cc7f22d4/{}1.0/{http://www.jcp.org/jcr/1.0}frozenNode/{}testNeu, /{http://www.jcp.org/jcr/1.0}system/{http://www.jcp.org/jcr/1.0}versionStorage/{}ef/{}d1/{}ce/{}efd1ce92b033299879aa009fabc40f49cc7f22d4/{}1.1/{http://www.jcp.org/jcr/1.0}frozenNode/{}testNeu]}

          at org.modeshape.jcr.cache.document.WritableSessionCache.persistChanges(WritableSessionCache.java:1433)

          at org.modeshape.jcr.cache.document.WritableSessionCache.save(WritableSessionCache.java:701)

          at org.modeshape.jcr.JcrVersionManager.remove(JcrVersionManager.java:1056)

          at de.company.contentrepository.modeshapebundle.ModeshapeDeleteTest.testDeleteVersionedNode(ModeshapeDeleteTest.java:83)

          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

          at java.lang.reflect.Method.invoke(Method.java:498)

          at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)

          at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)

          at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)

          at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)

          at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)

          at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)

          at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)

          at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)

          at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)

          at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)

          at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)

          at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)

          at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)

          at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)

          at org.junit.runners.ParentRunner.run(ParentRunner.java:309)

          at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)

          at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)

          at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)

          at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)

          at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)

          at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

       

       

       

      The problem is that the parent folder node still has references to the versions of the file node.

      We did not have this problem in modeshape 4.6.2 and 5.0.0. First occurence was in modeshape 5.1.0. We guess it has something to do with this change: MODE-2609 Fixes the type of the jcr:childVersionHistory property by hchiorean · Pull Request #1571 · ModeShape/modeshape…

       

      The attached test case reproduces the problem:

      - create parent node

      - create child node

      - create some versions of child node

      - remove all versions of child node

      - remove child node

       

      Our workaround so far is to move the child node to a non versionable tmp folder, remove the version references in the original parent folder and then remove the child node from the tmp folder. However, this should only be a temporary solution.

       

      Any help would be much appreciated!

       

      Greetings