[JBoss JIRA] (JBTM-2584) Failed commit during one-phase commit optimization only logs warning and lets EJB invocation succeed
by Torsten Roemer (JIRA)
Torsten Roemer created JBTM-2584:
------------------------------------
Summary: Failed commit during one-phase commit optimization only logs warning and lets EJB invocation succeed
Key: JBTM-2584
URL: https://issues.jboss.org/browse/JBTM-2584
Project: JBoss Transaction Manager
Issue Type: Bug
Environment: Ubuntu Linux 32Bit, Java 8, WildFly 8.2.1.Final
Reporter: Torsten Roemer
I have an entity manager (Oracle XA datasource) and a JCA resource adapter supporting LocalTransaction in one transaction.
Following scenario:
- An entity with values equal to those in the database is merged
- The commit() of the local-tx resource fails and throws a ResourceException
All that happens is a warning being logged:
{noformat}
00:34:47,619 WARN [com.arjuna.ats.jta] (default task-24) ARJUNA016039: onePhaseCommit on < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000101:25752588:566c9884:209, node_name=1, branch_uid=0:ffff7f000101:25752588:566c9884:211, subordinatenodename=null, eis_name=java:/FileDataSource > (LocalXAResourceImpl@41ac4d[connectionListener=d5fa3f connectionManager=1e7041 warned=false currentXid=null productName=Generic JCA productVersion=1.0 jndiName=java:/FileDataSource]) failed with exception XAException.XA_RBROLLBACK: org.jboss.jca.core.spi.transaction.local.LocalXAException: IJ001156: Could not commit local transaction
at org.jboss.jca.core.tx.jbossts.LocalXAResourceImpl.commit(LocalXAResourceImpl.java:180) [ironjacamar-core-impl-1.1.9.Final.jar:1.1.9.Final]
at com.arjuna.ats.internal.jta.resources.arjunacore.XAOnePhaseResource.commit(XAOnePhaseResource.java:113)
at com.arjuna.ats.internal.arjuna.abstractrecords.LastResourceRecord.topLevelPrepare(LastResourceRecord.java:152)
at com.arjuna.ats.arjuna.coordinator.AbstractRecord.topLevelOnePhaseCommit(AbstractRecord.java:428)
at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2317)
at com.arjuna.ats.arjuna.coordinator.BasicAction.prepare(BasicAction.java:2110)
at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1481)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:96)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1166)
at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) [wildfly-ejb3-8.2.1.Final.jar:8.2.1.Final]
{noformat}
and the EJB invocation succeeds.
I would expect the EJB to receive a RollbackException since the commit failed with XAException.XA_RBROLLBACK.
Debugging BasicAction.prepare(), I can see that because the outcome of prepare is TwoPhaseOutcome.PREPARE_READONLY, one phase commit optimization is applied and onePhaseCommit() is called where the outcome TwoPhaseOutcome.ONE_PHASE_ERROR isn't considered an error as far as I understand.
Then TwoPhaseOutcome.PREPARE_ONE_PHASE_COMMITTED is returned from BasicAction.prepare().
I would never expect the EJB invocation to succeed if any participant in the transaction fails to commit.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (JBTM-2583) Try to contact the transaction status connection manager to determine if a transaction containing XAResources is still in-flight before relying on orphan detection
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2583?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson reassigned JBTM-2583:
-----------------------------------
Assignee: Tom Jenkinson
> Try to contact the transaction status connection manager to determine if a transaction containing XAResources is still in-flight before relying on orphan detection
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-2583
> URL: https://issues.jboss.org/browse/JBTM-2583
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: Recovery
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 5.next
>
>
> Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager.
> This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back.
>
> There are a couple of advantages to this:
> 1. In the common case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely
> 2. In the case where the recovery manager and transaction manager are distributed, the current behaviour of orphan detection can be employed (or the timeout interval extended)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (JBTM-2583) Try to contact the transaction status connection manager to determine if a transaction containing XAResources is still in-flight before relying on orphan detection
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2583?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2583:
-------------------------------------
Note the comment on the discussion about this not being the default if it is backported
> Try to contact the transaction status connection manager to determine if a transaction containing XAResources is still in-flight before relying on orphan detection
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-2583
> URL: https://issues.jboss.org/browse/JBTM-2583
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: Recovery
> Reporter: Tom Jenkinson
> Fix For: 5.next
>
>
> Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager.
> This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back.
>
> There are a couple of advantages to this:
> 1. In the common case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely
> 2. In the case where the recovery manager and transaction manager are distributed, the current behaviour of orphan detection can be employed (or the timeout interval extended)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (JBTM-2583) Try to contact the transaction status connection manager to determine if a transaction containing XAResources is still in-flight before relying on orphan detection
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBTM-2583?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated JBTM-2583:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1009981
Bugzilla Update: Perform
> Try to contact the transaction status connection manager to determine if a transaction containing XAResources is still in-flight before relying on orphan detection
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-2583
> URL: https://issues.jboss.org/browse/JBTM-2583
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: Recovery
> Reporter: Tom Jenkinson
> Fix For: 5.next
>
>
> Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager.
> This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back.
>
> There are a couple of advantages to this:
> 1. In the common case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely
> 2. In the case where the recovery manager and transaction manager are distributed, the current behaviour of orphan detection can be employed (or the timeout interval extended)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (JBTM-2583) Try to contact the transaction status connection manager to determine if a transaction containing XAResources is still in-flight before relying on orphan detection
by Tom Jenkinson (JIRA)
Tom Jenkinson created JBTM-2583:
-----------------------------------
Summary: Try to contact the transaction status connection manager to determine if a transaction containing XAResources is still in-flight before relying on orphan detection
Key: JBTM-2583
URL: https://issues.jboss.org/browse/JBTM-2583
Project: JBoss Transaction Manager
Issue Type: Feature Request
Components: Recovery
Reporter: Tom Jenkinson
Fix For: 5.next
Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager.
This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back.
There are a couple of advantages to this:
1. In the common case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely
2. In the case where the recovery manager and transaction manager are distributed, the current behaviour of orphan detection can be employed (or the timeout interval extended)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (JBTM-2575) When checking for orphaned subordinate transactions in the middle of a tree branches that are eligible for orphan detection will be rolled back
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2575?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2575:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> When checking for orphaned subordinate transactions in the middle of a tree branches that are eligible for orphan detection will be rolled back
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-2575
> URL: https://issues.jboss.org/browse/JBTM-2575
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Recovery
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Priority: Blocker
> Fix For: 4.17.31, 5.next
>
>
> There is a check in the subordinate orphan detection that not only checks for matching gtrid but also for matching subordinate name. This will not match correctly for an intermediary node. E.g.
> a->b b->c
> When b scans c the xid it gets back will have subordinate name of c, b will look in its object store and match the subordinate on gtrid but the subordinate node ID in b subordinateatomicaction will be "b".
> This check is actually superfluous anyway. We already know that the Xid returned from c was for b because of transport level checks.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (JBTM-2579) Throw XAException in XATerminator::commit if a wrapped resource fails transiently
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2579?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2579:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Throw XAException in XATerminator::commit if a wrapped resource fails transiently
> ---------------------------------------------------------------------------------
>
> Key: JBTM-2579
> URL: https://issues.jboss.org/browse/JBTM-2579
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Priority: Critical
> Fix For: 4.17.31, 5.next
>
>
> It is possible for a resource that we are wrapping to return say XA_RETRY or XA_RMFAIL and therefore end up in the BasicAction failed list. However there is no error returned from commit in this circumstance as the recovery manager should ensure a consistent outcome.
> The reason this becomes a problem for JTA and XATerminator in particular is that as no error is returned a parent coordinator will assume the branch completed successfully. In the future when it calls XATerminator::recover though this branch will be returned and detected as an orphan.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (JBTM-2581) JMH benchmark failure
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2581?page=com.atlassian.jira.plugin.... ]
Michael Musgrove closed JBTM-2581.
----------------------------------
Resolution: Won't Fix
> JMH benchmark failure
> ---------------------
>
> Key: JBTM-2581
> URL: https://issues.jboss.org/browse/JBTM-2581
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Performance Testing
> Affects Versions: 5.2.8.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Minor
>
> The benchmark comparison job (http://albany.eng.hst.ams2.redhat.com/job/narayana-benchmarks/66) failed with the following:
> org.openjdk.jmh.runner.link.OutputFrame.data of type [B in instance of org.openjdk.jmh.runner.link.OutputFrame
> at java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2089)
> at java.io.ObjectStreamClass.setObjFieldValues(ObjectStreamClass.java:1261)
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2006)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1924)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1801)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2000)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1924)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1801)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
> at org.openjdk.jmh.runner.link.BinaryLinkServer$Handler.run(BinaryLinkServer.java:253)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (JBTM-2582) Re-enable SimpleIsolatedServers test
by Michael Musgrove (JIRA)
Michael Musgrove created JBTM-2582:
--------------------------------------
Summary: Re-enable SimpleIsolatedServers test
Key: JBTM-2582
URL: https://issues.jboss.org/browse/JBTM-2582
Project: JBoss Transaction Manager
Issue Type: Bug
Components: JTS
Affects Versions: 5.0.2
Reporter: Michael Musgrove
Assignee: Michael Musgrove
Fix For: 5.next
During the changes to support IBM orb this test was acidently excluded (in ArjunaJTS/integration/pom.xml).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months