jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Poulsen (JIRA)" <j...@apache.org>
Subject [jira] [Created] (JCR-3659) VersionManager.getVersionHistory followed by VersionManager.checkpoint in transaction fails
Date Tue, 27 Aug 2013 07:44:51 GMT
Chris Poulsen created JCR-3659:
----------------------------------

             Summary: VersionManager.getVersionHistory followed by VersionManager.checkpoint
in transaction fails
                 Key: JCR-3659
                 URL: https://issues.apache.org/jira/browse/JCR-3659
             Project: Jackrabbit Content Repository
          Issue Type: Bug
    Affects Versions: 2.4.4, 2.6.3
         Environment: Atomikos TX manager, H2 database (in-memory) 
            Reporter: Chris Poulsen


I'm seeing the exception below when performing the following operations: 

Tx-1 (Bootstrap node):
<begin transaction>
  1) Create mix:versionable node called "node" in repository root.
  2) Session.save()
  3) VersionManager.checkpoint( "/node" )
<finish transaction>

Then I do:
Tx-2 (Simplified code that fails):
<begin transaction>
  1) Get version history by doing VersionManager.getVersionHistory( "/node" ) (do nothing
with the return value)
  2) VersionManager.checkpoint( "/node" )
<finish transaction>


java.lang.RuntimeException: javax.jcr.InvalidItemStateException: Could not find child 35932dba-2ca3-40d8-94a9-762f2328be59
of node 3d10e0a6-0e8e-4ff5-8c9b-f75ccd63816d
    at com.dezide.webauthor.core.dao.JackrabbitTest$2.doInTransactionWithoutResult(JackrabbitTest.java:65)
    at org.springframework.transaction.support.TransactionCallbackWithoutResult.doInTransaction(TransactionCallbackWithoutResult.java:33)
    at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:131)
    at com.dezide.webauthor.core.dao.JackrabbitTest.testVersionHistoryBug(JackrabbitTest.java:47)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
    at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
    at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:74)
    at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:202)
    at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:65)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: javax.jcr.InvalidItemStateException: Could not find child 35932dba-2ca3-40d8-94a9-762f2328be59
of node 3d10e0a6-0e8e-4ff5-8c9b-f75ccd63816d
    at org.apache.jackrabbit.core.ItemManager.getDefinition(ItemManager.java:207)
    at org.apache.jackrabbit.core.ItemData.getDefinition(ItemData.java:99)
    at org.apache.jackrabbit.core.ItemManager.canRead(ItemManager.java:421)
    at org.apache.jackrabbit.core.ItemManager.createItemData(ItemManager.java:843)
    at org.apache.jackrabbit.core.ItemManager.getItemData(ItemManager.java:391)
    at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:328)
    at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:622)
    at org.apache.jackrabbit.core.SessionImpl.getNodeById(SessionImpl.java:536)
    at org.apache.jackrabbit.core.VersionManagerImpl$3.perform(VersionManagerImpl.java:162)
    at org.apache.jackrabbit.core.VersionManagerImpl$3.perform(VersionManagerImpl.java:154)
    at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
    at org.apache.jackrabbit.core.VersionManagerImpl.perform(VersionManagerImpl.java:96)
    at org.apache.jackrabbit.core.VersionManagerImpl.checkpoint(VersionManagerImpl.java:154)
    at com.dezide.webauthor.core.dao.JackrabbitTest$2.doInTransactionWithoutResult(JackrabbitTest.java:61)
    ... 32 more

The child node id from the exception does (obviously) not exist, while the node "3d10e0a6-0e8e-4ff5-8c9b-f75ccd63816d"
is of VersionHistory type (retrieved in debugger). 

I don't think that retrieving a version history should produce changes related to creating
a checkpoint, but it seems like something happens. Moving the getVersionHistory call outside
the transaction or suspending the transaction while retrieving the history get things going
again, but it is not really a long term solution.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message