[JBoss JIRA] (JBTM-1641) EAP 6.1 CNFE org.jboss.tm.TxManager (from Module org.jboss.jboss-transaction-spi:main)
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-1641?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-1641:
-----------------------------------
Priority: Minor (was: Major)
> EAP 6.1 CNFE org.jboss.tm.TxManager (from Module org.jboss.jboss-transaction-spi:main)
> --------------------------------------------------------------------------------------
>
> Key: JBTM-1641
> URL: https://issues.jboss.org/browse/JBTM-1641
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Application Server Integration
> Affects Versions: 4.17.3
> Reporter: Darryl Miles
> Assignee: Michael Musgrove
> Priority: Minor
> Fix For: 5.0.0.M4
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> When enabling additional logging to system DEBUG on startup of standalone-full.xml it is possible to see:
> 07:15:40,780 DEBUG [org.jboss.tm.TransactionManagerLocator] (MSC service thread 1-2) Unable to lookup: java:/TransactionManager: javax.naming.NameNotFoundException: Error looking up TransactionManager, service service jboss.naming.context.java.TransactionManager is not started
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:132) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:80) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:197) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:120) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:183) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) [jboss-as-naming-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_17]
> at org.jboss.tm.TransactionManagerLocator.tryJNDI(TransactionManagerLocator.java:150) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.TransactionManagerLocator.locate(TransactionManagerLocator.java:131) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.TransactionManagerLocator.locateTransactionManager(TransactionManagerLocator.java:94) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.<init>(ServerVMClientUserTransaction.java:93) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.<clinit>(ServerVMClientUserTransaction.java:60) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.as.txn.service.ArjunaTransactionManagerService.start(ArjunaTransactionManagerService.java:115) [jboss-as-transactions-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 07:15:40,786 DEBUG [org.jboss.tm.TransactionManagerLocator] (MSC service thread 1-2) Unable to instantiate legacy transaction manager: java.lang.ClassNotFoundException: org.jboss.tm.TxManager from [Module "org.jboss.jboss-transaction-spi:main" from local module loader @634f6b14 (finder: local module finder @72ff20fb (roots: F:\Devel\deps\jboss-eap-6.1\modules,F:\Devel\deps\jboss-eap-6.1\modules\system\layers\base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) [jboss-modules.jar:1.2.0.CR1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) [jboss-modules.jar:1.2.0.CR1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) [jboss-modules.jar:1.2.0.CR1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) [jboss-modules.jar:1.2.0.CR1]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) [jboss-modules.jar:1.2.0.CR1]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_17]
> at java.lang.Class.forName(Class.java:188) [rt.jar:1.7.0_17]
> at org.jboss.tm.TransactionManagerLocator.usePrivateAPI(TransactionManagerLocator.java:172) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.TransactionManagerLocator.locate(TransactionManagerLocator.java:133) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.TransactionManagerLocator.locateTransactionManager(TransactionManagerLocator.java:94) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.<init>(ServerVMClientUserTransaction.java:93) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.<clinit>(ServerVMClientUserTransaction.java:60) [jboss-transaction-spi-7.0.0.Final.jar:7.0.0.Final]
> at org.jboss.as.txn.service.ArjunaTransactionManagerService.start(ArjunaTransactionManagerService.java:115) [jboss-as-transactions-7.2.0.Alpha1-redhat-4.jar:7.2.0.Alpha1-redhat-4]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBTM-1722) REST-AT participant support framework should have associated quickstarts
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-1722?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-1722:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
I have added the extra service quickstarts that deploy the service to wildfly.
I also cleaned up the other rts quickstarts.
> REST-AT participant support framework should have associated quickstarts
> ------------------------------------------------------------------------
>
> Key: JBTM-1722
> URL: https://issues.jboss.org/browse/JBTM-1722
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: REST
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Minor
> Fix For: 5.0.0.M4
>
> Original Estimate: 6 hours
> Remaining Estimate: 6 hours
>
> JBTM-1365 introduced the RTS wildfly subsystem and an interface for simplifying participant registration into a REST-AT transaction by providing callbacks for prepare/commit/rollback. We need some quickstarts that show how to use it:
> - a standalone example similar to https://github.com/jbosstm/quickstart/tree/master/rest-tx/service showing the difference between the two approaches to building services
> - showing integration with wildfly
> - one for recovery
> If we want to split the work between engineers that would be fine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBTM-1867) Confusing error logged after crash recovery on prepare when hornetq object store used
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1867?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-1867:
-----------------------------------
We should duplicate what the other object store implementations do for consistency: they produce warning messages. This is not a debug message or trace though: in this scenario it's not an error, but in general when asked to remove a state and finding it's not there is something a transaction system should warn about immediately.
> Confusing error logged after crash recovery on prepare when hornetq object store used
> -------------------------------------------------------------------------------------
>
> Key: JBTM-1867
> URL: https://issues.jboss.org/browse/JBTM-1867
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JTS
> Affects Versions: 4.17.7, 5.0.0.M3
> Reporter: Ondřej Chaloupka
> Assignee: Michael Musgrove
>
> There is logged an confusing error after crash recovery happens when server crashed in prepare phase.
> {code}
> 14:47:59,697 ERROR [stderr] (RequestProcessor-10) com.arjuna.ats.arjuna.exceptions.ObjectStoreException: java.lang.IllegalStateException: Cannot find add info 3
> 14:47:59,698 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqJournalStore.remove_committed(HornetqJournalStore.java:153)
> 14:47:59,698 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqObjectStoreAdaptor.remove_committed(HornetqObjectStoreAdaptor.java:186)
> 14:47:59,698 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.jta.resources.jts.orbspecific.XAResourceRecord.destroyState(XAResourceRecord.java:1271)
> 14:47:59,699 INFO [org.jboss.as.test.jbossts.common.TestXAResourceCommon] (Periodic Recovery) TestXAResourceCommon.isSameRM(xaResource=TestXAResourceRecovered(TestXAResourceCommon(0, null)))
> 14:47:59,699 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.jta.resources.jts.orbspecific.XAResourceRecord.rollback(XAResourceRecord.java:411)
> 14:47:59,699 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ArjunaOTS.OTSAbstractRecordPOA._invoke(OTSAbstractRecordPOA.java:213)
> 14:47:59,699 ERROR [stderr] (RequestProcessor-10) at org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:306)
> 14:47:59,699 ERROR [stderr] (RequestProcessor-10) at org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:626)
> 14:47:59,699 ERROR [stderr] (RequestProcessor-10) at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:769)
> 14:47:59,700 ERROR [stderr] (RequestProcessor-10) Caused by: java.lang.IllegalStateException: Cannot find add info 3
> 14:47:59,700 ERROR [stderr] (RequestProcessor-10) at org.hornetq.core.journal.impl.JournalImpl.appendDeleteRecord(JournalImpl.java:904)
> 14:47:59,700 ERROR [stderr] (RequestProcessor-10) at org.hornetq.core.journal.impl.JournalBase.appendDeleteRecord(JournalBase.java:163)
> 14:47:59,700 ERROR [stderr] (RequestProcessor-10) at org.hornetq.core.journal.impl.JournalImpl.appendDeleteRecord(JournalImpl.java:82)
> 14:47:59,701 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqJournalStore.remove_committed(HornetqJournalStore.java:151)
> 14:47:59,701 ERROR [stderr] (RequestProcessor-10) ... 7 more
> {code}
> This happens when hornetq object store is used. This is caused because of the rollback is called on resource two times. This is ok - this matches to OTS spec (https://bugzilla.redhat.com/show_bug.cgi?id=988724).
> But after the second call of rollback the TM tries to remove Xid from object store. But as the xid does not exist anymore the hornetq object store implementation throws exception that is logged directly on stderr:
> XAResourceRecord.destroyState does e.printStackTrace()
> I would propose to put this exception to debug or trace as it does not mean error in fact.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBTM-1867) Confusing error logged after crash recovery on prepare when hornetq object store used
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-1867?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka updated JBTM-1867:
-----------------------------------
Affects Version/s: 5.0.0.M3
> Confusing error logged after crash recovery on prepare when hornetq object store used
> -------------------------------------------------------------------------------------
>
> Key: JBTM-1867
> URL: https://issues.jboss.org/browse/JBTM-1867
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JTS
> Affects Versions: 4.17.7, 5.0.0.M3
> Reporter: Ondřej Chaloupka
> Assignee: Michael Musgrove
>
> There is logged an confusing error after crash recovery happens when server crashed in prepare phase.
> {code}
> 14:47:59,697 ERROR [stderr] (RequestProcessor-10) com.arjuna.ats.arjuna.exceptions.ObjectStoreException: java.lang.IllegalStateException: Cannot find add info 3
> 14:47:59,698 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqJournalStore.remove_committed(HornetqJournalStore.java:153)
> 14:47:59,698 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqObjectStoreAdaptor.remove_committed(HornetqObjectStoreAdaptor.java:186)
> 14:47:59,698 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.jta.resources.jts.orbspecific.XAResourceRecord.destroyState(XAResourceRecord.java:1271)
> 14:47:59,699 INFO [org.jboss.as.test.jbossts.common.TestXAResourceCommon] (Periodic Recovery) TestXAResourceCommon.isSameRM(xaResource=TestXAResourceRecovered(TestXAResourceCommon(0, null)))
> 14:47:59,699 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.jta.resources.jts.orbspecific.XAResourceRecord.rollback(XAResourceRecord.java:411)
> 14:47:59,699 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ArjunaOTS.OTSAbstractRecordPOA._invoke(OTSAbstractRecordPOA.java:213)
> 14:47:59,699 ERROR [stderr] (RequestProcessor-10) at org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:306)
> 14:47:59,699 ERROR [stderr] (RequestProcessor-10) at org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:626)
> 14:47:59,699 ERROR [stderr] (RequestProcessor-10) at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:769)
> 14:47:59,700 ERROR [stderr] (RequestProcessor-10) Caused by: java.lang.IllegalStateException: Cannot find add info 3
> 14:47:59,700 ERROR [stderr] (RequestProcessor-10) at org.hornetq.core.journal.impl.JournalImpl.appendDeleteRecord(JournalImpl.java:904)
> 14:47:59,700 ERROR [stderr] (RequestProcessor-10) at org.hornetq.core.journal.impl.JournalBase.appendDeleteRecord(JournalBase.java:163)
> 14:47:59,700 ERROR [stderr] (RequestProcessor-10) at org.hornetq.core.journal.impl.JournalImpl.appendDeleteRecord(JournalImpl.java:82)
> 14:47:59,701 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqJournalStore.remove_committed(HornetqJournalStore.java:151)
> 14:47:59,701 ERROR [stderr] (RequestProcessor-10) ... 7 more
> {code}
> This happens when hornetq object store is used. This is caused because of the rollback is called on resource two times. This is ok - this matches to OTS spec (https://bugzilla.redhat.com/show_bug.cgi?id=988724).
> But after the second call of rollback the TM tries to remove Xid from object store. But as the xid does not exist anymore the hornetq object store implementation throws exception that is logged directly on stderr:
> XAResourceRecord.destroyState does e.printStackTrace()
> I would propose to put this exception to debug or trace as it does not mean error in fact.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBTM-1867) Confusing error logged after crash recovery on prepare when hornetq object store used
by Ondřej Chaloupka (JIRA)
Ondřej Chaloupka created JBTM-1867:
--------------------------------------
Summary: Confusing error logged after crash recovery on prepare when hornetq object store used
Key: JBTM-1867
URL: https://issues.jboss.org/browse/JBTM-1867
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JTS
Affects Versions: 4.17.7
Reporter: Ondřej Chaloupka
Assignee: Michael Musgrove
There is logged an confusing error after crash recovery happens when server crashed in prepare phase.
{code}
14:47:59,697 ERROR [stderr] (RequestProcessor-10) com.arjuna.ats.arjuna.exceptions.ObjectStoreException: java.lang.IllegalStateException: Cannot find add info 3
14:47:59,698 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqJournalStore.remove_committed(HornetqJournalStore.java:153)
14:47:59,698 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqObjectStoreAdaptor.remove_committed(HornetqObjectStoreAdaptor.java:186)
14:47:59,698 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.jta.resources.jts.orbspecific.XAResourceRecord.destroyState(XAResourceRecord.java:1271)
14:47:59,699 INFO [org.jboss.as.test.jbossts.common.TestXAResourceCommon] (Periodic Recovery) TestXAResourceCommon.isSameRM(xaResource=TestXAResourceRecovered(TestXAResourceCommon(0, null)))
14:47:59,699 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.jta.resources.jts.orbspecific.XAResourceRecord.rollback(XAResourceRecord.java:411)
14:47:59,699 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ArjunaOTS.OTSAbstractRecordPOA._invoke(OTSAbstractRecordPOA.java:213)
14:47:59,699 ERROR [stderr] (RequestProcessor-10) at org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:306)
14:47:59,699 ERROR [stderr] (RequestProcessor-10) at org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:626)
14:47:59,699 ERROR [stderr] (RequestProcessor-10) at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:769)
14:47:59,700 ERROR [stderr] (RequestProcessor-10) Caused by: java.lang.IllegalStateException: Cannot find add info 3
14:47:59,700 ERROR [stderr] (RequestProcessor-10) at org.hornetq.core.journal.impl.JournalImpl.appendDeleteRecord(JournalImpl.java:904)
14:47:59,700 ERROR [stderr] (RequestProcessor-10) at org.hornetq.core.journal.impl.JournalBase.appendDeleteRecord(JournalBase.java:163)
14:47:59,700 ERROR [stderr] (RequestProcessor-10) at org.hornetq.core.journal.impl.JournalImpl.appendDeleteRecord(JournalImpl.java:82)
14:47:59,701 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqJournalStore.remove_committed(HornetqJournalStore.java:151)
14:47:59,701 ERROR [stderr] (RequestProcessor-10) ... 7 more
{code}
This happens when hornetq object store is used. This is caused because of the rollback is called on resource two times. This is ok - this matches to OTS spec (https://bugzilla.redhat.com/show_bug.cgi?id=988724).
But after the second call of rollback the TM tries to remove Xid from object store. But as the xid does not exist anymore the hornetq object store implementation throws exception that is logged directly on stderr:
XAResourceRecord.destroyState does e.printStackTrace()
I would propose to put this exception to debug or trace as it does not mean error in fact.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBTM-1865) Transaction reported to be rolled back, although committed with one participant
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1865?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1865:
-------------------------------------
No problem, glad to be of help.
> Transaction reported to be rolled back, although committed with one participant
> -------------------------------------------------------------------------------
>
> Key: JBTM-1865
> URL: https://issues.jboss.org/browse/JBTM-1865
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 4.17.4
> Reporter: Christian von Kutzleben
> Assignee: Tom Jenkinson
>
> While testing recovery and transaction failures we came across
> two related issues, the test scenario is almost the same, I'll file the second issue shortly and update this ticket accordingly.
> Scenario:
> 2 enlisted XAResources (one for each database used by the test),
> The prepare phase is successful.
> We crash the first database server during the XAResource.commit invocation,
> _after_ it has committed it's branch, right before the control flow would return to the XAResource (which as a result throws a XAException.XA_RBCOMMFAIL).
> The TM can not know at this point in time, whether the database successfully committed the transaction or not. In this particular case, all changes have been committed.
> By definition of the 2PC protocol, the transaction should be considered as "to be committed", because the prepare phase has ended successfully.
> But now things go awry:
> 1. There is a XAResource.rollback() issued to the second XAResource.
> 2. The client receives a EJBTransactionRolledbackException, although
> one branch has been completed.
> Note, that our database does not support heuristical completion of a branch at all, i.e. there should be no Heuristic* exception be thrown either.
> The correct behavior is, to report the transaction as success to the client, commit all branches. All XAResources which failed during XAResource.commit() are supposed to be recovered in future.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBTM-1865) Transaction reported to be rolled back, although committed with one participant
by Christian von Kutzleben (JIRA)
[ https://issues.jboss.org/browse/JBTM-1865?page=com.atlassian.jira.plugin.... ]
Christian von Kutzleben commented on JBTM-1865:
-----------------------------------------------
Hi Tom,
you're right, I've overseen that comment yesterday, when quickly trying out an "generic" error code.
Anyways, I've changed that to XAERR_RMFAIL now and it works as expected (at least the commit behavior,
have not verified recovery yet)
Thank you!
Christian
> Transaction reported to be rolled back, although committed with one participant
> -------------------------------------------------------------------------------
>
> Key: JBTM-1865
> URL: https://issues.jboss.org/browse/JBTM-1865
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 4.17.4
> Reporter: Christian von Kutzleben
> Assignee: Tom Jenkinson
>
> While testing recovery and transaction failures we came across
> two related issues, the test scenario is almost the same, I'll file the second issue shortly and update this ticket accordingly.
> Scenario:
> 2 enlisted XAResources (one for each database used by the test),
> The prepare phase is successful.
> We crash the first database server during the XAResource.commit invocation,
> _after_ it has committed it's branch, right before the control flow would return to the XAResource (which as a result throws a XAException.XA_RBCOMMFAIL).
> The TM can not know at this point in time, whether the database successfully committed the transaction or not. In this particular case, all changes have been committed.
> By definition of the 2PC protocol, the transaction should be considered as "to be committed", because the prepare phase has ended successfully.
> But now things go awry:
> 1. There is a XAResource.rollback() issued to the second XAResource.
> 2. The client receives a EJBTransactionRolledbackException, although
> one branch has been completed.
> Note, that our database does not support heuristical completion of a branch at all, i.e. there should be no Heuristic* exception be thrown either.
> The correct behavior is, to report the transaction as success to the client, commit all branches. All XAResources which failed during XAResource.commit() are supposed to be recovered in future.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months