You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Diego Munguia (JIRA)" <ji...@apache.org> on 2008/01/19 00:01:52 UTC
[jira] Updated: (JCR-566) Versioning bug with restore and
transactions
[ 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.