You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Sven Rieckhoff (JIRA)" <ji...@apache.org> on 2008/04/24 12:03:21 UTC
[jira] Created: (JCR-1554) StaleItemStateException with distributed
transactions
StaleItemStateException with distributed transactions
-----------------------------------------------------
Key: JCR-1554
URL: https://issues.apache.org/jira/browse/JCR-1554
Project: Jackrabbit
Issue Type: Bug
Components: transactions
Affects Versions: core 1.4.2, 1.4
Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
PM of repository: OraclePersistenceManager; DB: Oracle
Reporter: Sven Rieckhoff
There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
Scenario A (setProperty):
(1) multiple setProperty() with same property name on the same node (newly created or already existent)
=> With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
Scenario B (deleteNode):
(1) iterate 10 times:
(1.1) create new node n and a subnode for n
(1.2) delete node n
=> Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
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
at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy9.setNodeProperty(Unknown Source)
at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
at org.testng.TestRunner.runWorkers(TestRunner.java:689)
at org.testng.TestRunner.privateRun(TestRunner.java:566)
at org.testng.TestRunner.run(TestRunner.java:466)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
at org.testng.SuiteRunner.run(SuiteRunner.java:191)
at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
at org.testng.TestNG.run(TestNG.java:701)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
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:1028)
... 30 more
Caused by: javax.transaction.xa.XAException
at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
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)
... 36 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:138)
... 40 more
Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
... 41 more
When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1554) StaleItemStateException with
distributed transactions
Posted by "Philipp Salzgeber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668045#action_12668045 ]
Philipp Salzgeber commented on JCR-1554:
----------------------------------------
this issue is breaking most of our automated tests. It looks like jackrabbit transaction support is thoroughly broken.
Redhat Enterprise Linux WS Rel 4, jrockit_150_12, bea weblogic 9.2, jackrabbit 1.5, spring 2.5.5, spring-modules-jcr 0.9
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1554) StaleItemStateException with
distributed transactions
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704944#action_12704944 ]
Jukka Zitting commented on JCR-1554:
------------------------------------
> I still get this error with 1.4.9.
The fix is included in the 1.5.3 release.
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Fix For: 1.5.3
>
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1554) StaleItemStateException with
distributed transactions
Posted by "Dominique Pfister (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dominique Pfister resolved JCR-1554.
------------------------------------
Resolution: Fixed
Fixed by updating the states contained in the transactional change log, as well. Added 2 test cases in XATest (testSetProperty and testDeleteNode) that mimic the behaviour of the TestNG test cases, especially reusing the same session for subsequent transactions, which effectively let the different transactions operate on the same PropertyImpl and NodeImpl instances, respectively.
Fixed in revision 741652.
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1554) StaleItemStateException with
distributed transactions
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704951#action_12704951 ]
Jukka Zitting commented on JCR-1554:
------------------------------------
I don't see your point, JCR -1554 is listed as a known issue for 1.4.5. In other words, we knew that this issue was *not* fixed in 1.4.5.
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Fix For: 1.5.3
>
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1554) StaleItemStateException with distributed
transactions
Posted by "Manfred Mayr (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Manfred Mayr updated JCR-1554:
------------------------------
Comment: was deleted
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1554) StaleItemStateException with distributed
transactions
Posted by "Juergen Melzer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Juergen Melzer updated JCR-1554:
--------------------------------
Comment: was deleted
(was: oh sorry. you are right.)
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Fix For: 1.5.3
>
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1554) StaleItemStateException with
distributed transactions
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600502#action_12600502 ]
Stefan Guggisberg commented on JCR-1554:
----------------------------------------
> Stephane Landelle commented on JCR-1554:
> ----------------------------------------
>
> I have the same problem, and we won't ever be able to go in production with it...
>
> I have the feeling it comes from the Session being reused but its cache not being cleared at the end of a transaction, when refresh(false) is called.
> It seems the bug dissapears when I add a itemMgr.dispose(); in SessionImpl.refresh :
i'm afraid that your proposed workaround would violate ItemManager's contract, see:
http://jackrabbit.apache.org/api/1.4/org/apache/jackrabbit/core/ItemManager.html
<quote>
The ItemManager's responsabilities are:
[...]
guaranteeing that there aren't multiple instances representing the same Node or Property associated with the same Session instance.
</quote>
your proposed change could lead to multiple Node or Property instances per session representing the same item.
this would cause serious consistency issues.
-1 for the proposed change.
>
> public void refresh(boolean keepChanges) throws RepositoryException {
> // check sanity of this session
> sanityCheck();
>
> if (!keepChanges) {
> // optimization
> itemStateMgr.disposeAllTransientItemStates();
> itemMgr.dispose();
> return;
> }
> itemMgr.getRootNode().refresh(keepChanges);
> }
>
> I'm not sure of the impact of this change, so could somebody of Jackrabbit have a look at it, please?
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit
> Issue Type: Bug
> Components: transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1554) StaleItemStateException with distributed
transactions
Posted by "Juergen Melzer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Juergen Melzer updated JCR-1554:
--------------------------------
Comment: was deleted
(was: This Bug is not closed.
I still get this error with 1.4.9.
I wrote a jmeter script to test our application and I get this error after few requests.)
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Fix For: 1.5.3
>
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1554) StaleItemStateException with
distributed transactions
Posted by "Juergen Melzer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704950#action_12704950 ]
Juergen Melzer commented on JCR-1554:
-------------------------------------
Thats not correct. See the release notes for 1.4.5
http://www.nabble.com/-ANNOUNCE--jackrabbit-core-1.4.5-released-td17750572.html#a17750572
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Fix For: 1.5.3
>
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1554) StaleItemStateException with distributed
transactions
Posted by "Juergen Melzer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Juergen Melzer updated JCR-1554:
--------------------------------
Comment: was deleted
(was: Thats not correct. See the release notes for 1.4.5
http://www.nabble.com/-ANNOUNCE--jackrabbit-core-1.4.5-released-td17750572.html#a17750572)
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Fix For: 1.5.3
>
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1554) StaleItemStateException with
distributed transactions
Posted by "Philipp Salzgeber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672294#action_12672294 ]
Philipp Salzgeber commented on JCR-1554:
----------------------------------------
we are using 1.5
thx,
Philipp
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1554) StaleItemStateException with distributed
transactions
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-1554:
-------------------------------
Fix Version/s: 1.5.3
Merged to the 1.5 branch in revision 743343. This fix will be included in the 1.5.3 release.
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Fix For: 1.5.3
>
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1554) StaleItemStateException with distributed
transactions
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-1554:
-------------------------------
Component/s: jackrabbit-core
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1554) StaleItemStateException with
distributed transactions
Posted by "Juergen Melzer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704954#action_12704954 ]
Juergen Melzer commented on JCR-1554:
-------------------------------------
oh sorry. you are right.
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Fix For: 1.5.3
>
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1554) StaleItemStateException with
distributed transactions
Posted by "Dominique Pfister (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671225#action_12671225 ]
Dominique Pfister commented on JCR-1554:
----------------------------------------
Verified that if the fix to XAItemStateManager is applied to jackrabbit-core-1.4.2, the TestNG tests will run without failures and no exceptions occur.
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1554) StaleItemStateException with
distributed transactions
Posted by "Philipp Salzgeber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670760#action_12670760 ]
Philipp Salzgeber commented on JCR-1554:
----------------------------------------
with this fix in place:
$ diff ItemState.java ItemState.java.bak
152c152
< synchronized void pull() {
---
> synchronized void pull() {
155,158c155
< // sync modification count top down
< if (state.isConnected()) {
< state.pull();
< }
---
> // sync modification count
161c158
< }
---
> }
I was able to run our regression suite without unexpected rollback transaction coming up, additionally manual tests in variouse parts of our application did not show issues.
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1554) StaleItemStateException with
distributed transactions
Posted by "Dominique Pfister (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672288#action_12672288 ]
Dominique Pfister commented on JCR-1554:
----------------------------------------
Hi Philipp,
Not sure about this: since the change is very small and unlikely to cause problems, I assume that a fix for this will be contained in 1.5.3, which should be released quite soon. Are you already using 1.5 or able to upgrade?
Kind regards
Dominique
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1554) StaleItemStateException with distributed
transactions
Posted by "Sven Rieckhoff (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sven Rieckhoff updated JCR-1554:
--------------------------------
Attachment: jackrabbit-tx-bug.zip
As announced a simple java application demonstrating the bug...
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit
> Issue Type: Bug
> Components: transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1554) StaleItemStateException with
distributed transactions
Posted by "Martin Schreiber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670446#action_12670446 ]
Martin Schreiber commented on JCR-1554:
---------------------------------------
It might be that the following explanation is not as it really is, so feel free to correct me:
An ItemState might have an overlayedState. What I have seen from debugging with lots of logging is that an itemState could have an overlayedState and this overlayedState could also have an overlayedState and so on.
If there is a e.g. a property change the ItemStateManger(s) gets "informed" and the "stateModified" method is called.
In transactions the the XAItemStateManager's (which is a sub class of the LocalItemStateManager) "stateModified" method is called.
If the state already exists the "pull()" method is called on that state (ItemState.pull()). The idea of the pull method is to sync up the modification counter with the overlayedState. And here is the issue IMHO because it is only done "one layer down" and not top down.
If I saw it correctly, with the provided test class, setting a property the first time will end up in one ItemState, setting it the 2nd time you will have an itemState with an overlayedState, calling it the 3rd time, you have itemState->overlayedState->overlayedState. If than "pull()" is called to sync up the modCount, it is only done with the itemState->overlayedState and not with the itemState->overlayedState->overlayedState....thats IMHO the reason why you see it at the 3rd time and not before.
To cut a long story short, here what i changed:
ItemState.java (line 152ff):
original:
synchronized void pull() {
ItemState state = overlayedState;
if (state != null) {
// sync modification count
copy(state, true);
}
}
my modification:
synchronized void pull() {
ItemState state = overlayedState;
if (state != null) {
// sync modification count top down
if (state.isConnected()) {
state.pull();
}
copy(state, true);
}
}
With that change I was able to a) build jackrabbit and b) run the provided TestNG successfully without the RollbackException (for both tests, setting the item property and deleting a node).
Jackrabbit guys, could you please take a look at my proposal.
Thanks!!
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1554) StaleItemStateException with
distributed transactions
Posted by "Yoav Landman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625540#action_12625540 ]
Yoav Landman commented on JCR-1554:
-----------------------------------
We have the same problem which is also becoming a production issue. Any idea if there is a valid patch for this or when it will be resolved?
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit
> Issue Type: Bug
> Components: transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1554) StaleItemStateException with
distributed transactions
Posted by "Juergen Melzer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704942#action_12704942 ]
Juergen Melzer commented on JCR-1554:
-------------------------------------
This Bug is not closed.
I still get this error with 1.4.9.
I wrote a jmeter script to test our application and I get this error after few requests.
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Fix For: 1.5.3
>
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1554) StaleItemStateException with
distributed transactions
Posted by "Dominique Pfister (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670829#action_12670829 ]
Dominique Pfister commented on JCR-1554:
----------------------------------------
Hi,
Martin and Philipp, thanks for your input, which helped me a lot understanding what is going wrong here and why. As far as I can tell right now, the issue is caused by the local property state, referenced in the XAItemStateManager's change log, which is not being updated ("pulled") correctly at the end of a save operation. Usually, this happens inside SharedItemStateManager.Update.end():
try {
/* Let the shared item listeners know about the change */
---> shared.persisted();
// downgrade to read lock
Among others, this will notify the XAItemStateManager about the changes made to the property state (modcount increased by 1). Its stateModified() implementation, which is actually contained in the super class LocalItemStateManager, looks like this:
// shared state was modified
---> local = cache.retrieve(modified.getId());
if (local != null && local.isConnected()) {
// this instance represents existing state, update it
local.pull();
}
Without transactions, the local state will be contained in the cache. With transactions, on the other hand, the local state will only be contained in the current transaction's change log, so there will be no update to this state and the modcount stays at its current value.
Looking at the modcounts of the property states in the transient (T), local (L) and shared (S) layers, one can watch the following behaviours in the successive calls to Property.setValue():
1) T: 0, L: N/A, S:N/A (obviously, because the first operation *creates* the property state)
2) T: 0, L: 0, S: 0
3) T: 0, L: 0, S: 1
which explains why the 3rd operation wil fail.
I'll further look into this tomorrow, so please stay tuned!
Kind regards
Dominique
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1554) StaleItemStateException with
distributed transactions
Posted by "Stephane Landelle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599893#action_12599893 ]
Stephane Landelle commented on JCR-1554:
----------------------------------------
I have the same problem, and we won't ever be able to go in production with it...
I have the feeling it comes from the Session being reused but its cache not being cleared at the end of a transaction, when refresh(false) is called.
It seems the bug dissapears when I add a itemMgr.dispose(); in SessionImpl.refresh :
public void refresh(boolean keepChanges) throws RepositoryException {
// check sanity of this session
sanityCheck();
if (!keepChanges) {
// optimization
itemStateMgr.disposeAllTransientItemStates();
itemMgr.dispose();
return;
}
itemMgr.getRootNode().refresh(keepChanges);
}
I'm not sure of the impact of this change, so could somebody of Jackrabbit have a look at it, please?
Thank you,
Stéphane Landelle
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit
> Issue Type: Bug
> Components: transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1554) StaleItemStateException with
distributed transactions
Posted by "Manfred Mayr (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670645#action_12670645 ]
Manfred Mayr commented on JCR-1554:
-----------------------------------
Das sieht wirklich nicht schlecht aus!
Scheint, also ob du den Jackrabbit Jungs zeigst, wie gehen sollte:-)
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1554) StaleItemStateException with
distributed transactions
Posted by "Philipp Salzgeber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672262#action_12672262 ]
Philipp Salzgeber commented on JCR-1554:
----------------------------------------
Hi Dominique,
thnx for resolving the issue! Any idea when this will be released?
thx,
Philipp
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1554) StaleItemStateException with
distributed transactions
Posted by "Martin Schreiber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670826#action_12670826 ]
Martin Schreiber commented on JCR-1554:
---------------------------------------
If this is the fix for that issue, updating also the push method might be good as well.
void push() {
ItemState state = overlayedState;
if (state != null) {
if (state.isConnected()) {
state.getOverlayedState().copy(this, false);
}
state.copy(this, false);
}
}
> StaleItemStateException with distributed transactions
> -----------------------------------------------------
>
> Key: JCR-1554
> URL: https://issues.apache.org/jira/browse/JCR-1554
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.4, core 1.4.2
> Environment: WinXP, jdk1.5.0_14, jboss_4.2.2.GA, jackrabbit 1.4.2, spring 2.5.3, spring-modules-jcr 0.8 (for integration of jackrabbit with spring)
> PM of repository: OraclePersistenceManager; DB: Oracle
> Reporter: Sven Rieckhoff
> Attachments: jackrabbit-tx-bug.zip
>
>
> There seams to be a serious bug in jackrabbit when used in distributed transactions. It does not occur with local transactions! And it seams to be related to JCR-566.
> There are 2 scenarios where a StaleItemStateException occurs reproducible that causes transactions to fail. All my operations (implemented in a custom ServiceBean) such as setProperty() or deleteNode() run in separate transactions. The transactions are configured through Spring Annotations (@Transactional).
> Scenario A (setProperty):
> (1) multiple setProperty() with same property name on the same node (newly created or already existent)
> => With the 3. setProperty() (and sometimes also the 5.), a StaleItemStateException for the property state is raised when the transaction is commited. Following setProperty invocations will not fail!
> Scenario B (deleteNode):
> (1) iterate 10 times:
> (1.1) create new node n and a subnode for n
> (1.2) delete node n
> => Deletion of node n raises a StaleItemStateException for node n in iteration 1, 3 and (6 or 7), when the related transaction is commited. Following deletions of node n will also fail with a predictable pattern.
> The Exception trace for scenario A (it's the same for scenario B, with one difference: StaleItemStateException is raised for the node and not for the property):
> 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
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1031)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:709)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:678)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy9.setNodeProperty(Unknown Source)
> at de.zeb.control.prototype.jrTxBug.test.TestJackrabbitTxBug.testTransactionBug001(TestJackrabbitTxBug.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:478)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:607)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:874)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:689)
> at org.testng.TestRunner.privateRun(TestRunner.java:566)
> at org.testng.TestRunner.run(TestRunner.java:466)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:301)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:296)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:276)
> at org.testng.SuiteRunner.run(SuiteRunner.java:191)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:808)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:776)
> at org.testng.TestNG.run(TestNG.java:701)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124)
> 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:1028)
> ... 30 more
> Caused by: javax.transaction.xa.XAException
> at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:155)
> 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)
> ... 36 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:138)
> ... 40 more
> Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: bef3c056-bc91-4195-a35c-aa184182b5ad/{}TEST_PROPERTY has been modified externally
> at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:620)
> at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:843)
> at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:144)
> ... 41 more
> When debugging into jackrabbit you will see, that the cause of the StaleItemStateException is, that the local state und the overlayed state differ in the value of the 'modCount' attribute: modCount of local state is lower than modCount of overlayed state. Perhaps its a state caching problem...
>
> I'm attaching a simple java application configured with maven and ready to run standalone. The JCA container of JBoss is therefore replaced with jencks in order to support distributed transactions. The configured repository uses the InMemPersistenceManager. Both scenarios are implemented in a TestNG - test, that catches the occuring TransactionExceptions and prints out the stacktrace. Therefore you will see the exceptions, but the tests will not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.