Details

      Description

      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.

      1. debug1.py
        4 kB
        Florent Guillaume
      2. VersionBugReplicate.tar.gz
        9.79 MB
        Diego Munguia

        Activity

        Hide
        Florent Guillaume added a comment -

        Attaching jython program used to demonstrate the bug.
        This is with Jython 2.1 and
        java version "1.5.0_06"
        Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112)
        Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing)
        (on Mac OS X 10.4)

        Show
        Florent Guillaume added a comment - Attaching jython program used to demonstrate the bug. This is with Jython 2.1 and java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) (on Mac OS X 10.4)
        Hide
        Diego Munguia added a comment -

        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

        Show
        Diego Munguia added a comment - 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
        Hide
        quipere added a comment -

        I have this same problem using jencks in tomcat6 with jackrabbit 1.5.5. Versioning icw distributed transactions. Is there any info on resolving or workaround this problem?

        Show
        quipere added a comment - I have this same problem using jencks in tomcat6 with jackrabbit 1.5.5. Versioning icw distributed transactions. Is there any info on resolving or workaround this problem?

          People

          • Assignee:
            Tobias Bocanegra
            Reporter:
            Florent Guillaume
          • Votes:
            4 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:

              Development