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] [Commented] (JCR-3659) VersionManager.getVersionHistory followed by VersionManager.checkpoint in transaction fails
Date Wed, 04 Sep 2013 14:05:54 GMT

    [ https://issues.apache.org/jira/browse/JCR-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13757792#comment-13757792
] 

Chris Poulsen commented on JCR-3659:
------------------------------------

I've just been bit by this again :( 

It seems like performing the following two steps:
1) VersionManager.getVersionHistory(<checked-out-path>)
2) VersionManager.checkpoint(<checked-out-path>)

Makes the last step fail with the error in the issue... But only if the session is enlisted
in a transaction.

Can someone explain why performing this in a (XA)transaction fails, but works like expected
in a non-transactional environment? 
There are no pending changes or anything, but it seems like jackrabbit is trying to do access
some undefined version or something weird like that during check-in in the transactional case.
                
> 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
>         Attachments: test-jcr3659.zip
>
>
> 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