[
https://issues.apache.org/jira/browse/JCR-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diego Munguia updated JCR-566:
------------------------------
Attachment: VersionBugReplicate.tar.gz
I hope this is somehow helpful for you guys, as I'm very interested on a
solution for this particular bug. I'm attaching a small Java application that
reproduces this bug. It requires an empty mysql database (for Jackrabbit
persistence) called VersionBugReplicate with username = test and password =
test. The repository was located in /tmp/repository. Included in the tar.gz
file are the IDEA project files for a faster setup.
The code uses mysql db persistence, spring (and the @Transactional annotation),
jencks, geronimo transaction management and enhydra data source. (This is a
very similar to the setup I'm using in the application I'm currently working on)
OS: MacOS X 10.4.11
java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241)
Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing)
I noticed this bug only happens when using distributed transactions, this same
code executed succesfully using local transactions.
The bug happens when a node gets updated just after it was restored from
version history. This is application output:
content = The content of testNode-2850966957514740727
content = The content of testNode-2850966957514740727 - updated 1
testDAO.getLastModified(nodeName) = Fri Jan 18 16:34:59 CST 2008
content = The content of testNode-2850966957514740727 - updated 1 - updated 2
testDAO.getLastModified(nodeName) = Fri Jan 18 16:35:00 CST 2008
content = The content of testNode-2850966957514740727 - updated 1 - updated 2 -
updated 3
testDAO.getLastModified(nodeName) = Fri Jan 18 16:35:00 CST 2008
node restored to version 1 succesfully
content = The content of testNode-2850966957514740727 - updated 1
testDAO.getLastModified(nodeName) = Fri Jan 18 16:34:59 CST 2008
org.springframework.transaction.UnexpectedRollbackException: JTA transaction
unexpectedly rolled back (maybe due to a timeout); nested exception is
javax.transaction.RollbackException: Error during one-phase commit
Caused by: javax.transaction.RollbackException: Error during one-phase commit
at
org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:281)
at
org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:143)
at
org.apache.geronimo.transaction.context.InheritableTransactionContext.complete(InheritableTransactionContext.java:196)
at
org.apache.geronimo.transaction.context.InheritableTransactionContext.commit(InheritableTransactionContext.java:146)
at
org.apache.geronimo.transaction.context.OnlineUserTransaction.commit(OnlineUserTransaction.java:80)
at
org.jencks.factory.UserTransactionFactoryBean$GeronimoUserTransaction.commit(UserTransactionFactoryBean.java:118)
at
org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:842)
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:651)
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:621)
at
org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:311)
at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:117)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
at $Proxy6.updateTestNode(Unknown Source)
at versionbugreplicate.Main.main(Main.java:46)
Caused by: javax.transaction.xa.XAException
at
org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:143)
at
org.apache.jackrabbit.core.XASessionImpl.commit(XASessionImpl.java:337)
at
org.apache.jackrabbit.jca.TransactionBoundXAResource.commit(TransactionBoundXAResource.java:39)
at
org.apache.geronimo.transaction.manager.WrapperNamedXAResource.commit(WrapperNamedXAResource.java:47)
at
org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:272)
... 14 more
Caused by: org.apache.jackrabbit.core.TransactionException: Unable to prepare
transaction.
at
org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:150)
at
org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:126)
... 18 more
Caused by: org.apache.jackrabbit.core.state.StaleItemStateException:
7a7b7bbe-868d-43f0-b720-a84e991642c7/{http://www.jcp.org/jcr/1.0}data has been
modified externally
at
org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:604)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:825)
at
org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
... 19 more
> Versioning bug with restore and transactions
> --------------------------------------------
>
> Key: JCR-566
> URL: https://issues.apache.org/jira/browse/JCR-566
> Project: Jackrabbit
> Issue Type: Bug
> Components: transactions
> Affects Versions: 1.1
> Reporter: Florent Guillaume
> Assignee: Tobias Bocanegra
> Attachments: debug1.py, VersionBugReplicate.tar.gz
>
>
> This is a versioning bug in the presence of restore and transactions. It's
> hard to reproduce and seems memory-layout dependent.
> At the moment I only have a jython testcase, see below. This is with a svn
> checkout from today (442228).
> Basically the program does create a node and subnode and do some checkins,
> checkouts, restore, modifications, in successive transactions. Transactions
> are managed manually using the xaresource API, but it would be equivalent to
> use a UserTransaction (the sequence of xaresource calls in the end is the
> same).
> The program log and stack trace is:
> start 1
> node 36eca6a5-8e5d-46a8-897a-4b81734aaad4
> commit 1
> start 2
> commit 2
> start 3
> commit 3
> javax.transaction.xa.XAException
> at
> org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:138)
> at
> org.apache.jackrabbit.core.XASessionImpl.prepare(XASessionImpl.java:300)
> File "debug1.py", line 128, in doit
> File "debug1.py", line 145, in ?
> Caused by: org.apache.jackrabbit.core.TransactionException: Unable to prepare
> transaction.
> at
> org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:159)
> at
> org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:121)
> ... 22 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException:
> 36eca6a5-8e5d-46a8-897a-4b81734aaad4/{http://www.jcp.org/jcr/1.0}predecessors
> has been modified externally
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:546)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:717)
> at
> org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:151)
> ... 23 more
> javax.transaction.xa.XAException: javax.transaction.xa.XAException
> Note that the mentionned property (here, "jcr:predecessors") has changed when
> I was cutting down on the program size to get a simpler testcase. It's not
> necessarily a "system" property, and sometimes it was property of the subnode
> created under the main node.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
