[JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-1702:
-----------------------------------
JIRA is not a discussion forum. I fail to see why these conversations could not be taken to a forum, especially given that this entire thread is publicly viewable anyway!
> one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
> -------------------------------------------------------------------------------------------------
>
> Key: JBTM-1702
> URL: https://issues.jboss.org/browse/JBTM-1702
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Transaction Core
> Affects Versions: 5.0.0.M2
> Reporter: Christian von Kutzleben
> Assignee: Tom Jenkinson
> Fix For: 4.17.18, 5.0.2
>
> Attachments: JTATest.java
>
>
> We provide our own XAResource implementation for our database product,
> in our unit testsuite we do also test common error conditions.
> The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback.
> The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure.
> The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored.
> This error occurs if and only if the one-phase optimization is used, i.e. if
> exactly one XAResource instance is enlisted with the TransactionManager.
> If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully.
> The broken logic is contained in here (also see a complete stack trace below):
> com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
> Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes.
> FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure.
> This is the complete stacktrace of our exception (logged immediately prior before it was thrown):
> About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
> com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
> at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553)
> at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54)
> at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception
> 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:92)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1702:
-------------------------------------
Its difficult to work out if there is a bug or not based on the interaction so far. It is definitely best to discuss this over here: https://developer.jboss.org/en/jbosstm/ so we can better help you and our community. The forum is much better for discussion of whether something is an issue, once we have a clear picture then we can either raise an issue here in Jira or help to identify suitable changes elsewhere as appropriate.
> one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
> -------------------------------------------------------------------------------------------------
>
> Key: JBTM-1702
> URL: https://issues.jboss.org/browse/JBTM-1702
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Transaction Core
> Affects Versions: 5.0.0.M2
> Reporter: Christian von Kutzleben
> Assignee: Tom Jenkinson
> Fix For: 4.17.18, 5.0.2
>
> Attachments: JTATest.java
>
>
> We provide our own XAResource implementation for our database product,
> in our unit testsuite we do also test common error conditions.
> The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback.
> The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure.
> The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored.
> This error occurs if and only if the one-phase optimization is used, i.e. if
> exactly one XAResource instance is enlisted with the TransactionManager.
> If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully.
> The broken logic is contained in here (also see a complete stack trace below):
> com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
> Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes.
> FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure.
> This is the complete stacktrace of our exception (logged immediately prior before it was thrown):
> About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
> com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
> at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553)
> at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54)
> at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception
> 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:92)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
by Christian von Kutzleben (JIRA)
[ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.... ]
Christian von Kutzleben commented on JBTM-1702:
-----------------------------------------------
Sorry, I won't discuss that in the forum for reasons.
Also our position is, that this is clearly described, undeniable bug in the contract between bean container and
bean user (not between container and XAResource).
If you don't fix that, I would appreciate if you let our customer know, how he should handle the situation.
The only way I see right now is to enforce 2-phase-commit by enlisting a dummy XAResource in the bean.
> one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
> -------------------------------------------------------------------------------------------------
>
> Key: JBTM-1702
> URL: https://issues.jboss.org/browse/JBTM-1702
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Transaction Core
> Affects Versions: 5.0.0.M2
> Reporter: Christian von Kutzleben
> Assignee: Tom Jenkinson
> Fix For: 4.17.18, 5.0.2
>
> Attachments: JTATest.java
>
>
> We provide our own XAResource implementation for our database product,
> in our unit testsuite we do also test common error conditions.
> The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback.
> The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure.
> The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored.
> This error occurs if and only if the one-phase optimization is used, i.e. if
> exactly one XAResource instance is enlisted with the TransactionManager.
> If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully.
> The broken logic is contained in here (also see a complete stack trace below):
> com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
> Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes.
> FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure.
> This is the complete stacktrace of our exception (logged immediately prior before it was thrown):
> About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
> com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
> at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553)
> at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54)
> at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception
> 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:92)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1702:
-------------------------------------
Please can you create a forum topic to discuss this? It's best to discuss on there so that the community can all contribute.
> one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
> -------------------------------------------------------------------------------------------------
>
> Key: JBTM-1702
> URL: https://issues.jboss.org/browse/JBTM-1702
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Transaction Core
> Affects Versions: 5.0.0.M2
> Reporter: Christian von Kutzleben
> Assignee: Tom Jenkinson
> Fix For: 4.17.18, 5.0.2
>
> Attachments: JTATest.java
>
>
> We provide our own XAResource implementation for our database product,
> in our unit testsuite we do also test common error conditions.
> The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback.
> The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure.
> The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored.
> This error occurs if and only if the one-phase optimization is used, i.e. if
> exactly one XAResource instance is enlisted with the TransactionManager.
> If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully.
> The broken logic is contained in here (also see a complete stack trace below):
> com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
> Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes.
> FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure.
> This is the complete stacktrace of our exception (logged immediately prior before it was thrown):
> About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
> com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
> at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553)
> at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54)
> at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception
> 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:92)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
by Christian von Kutzleben (JIRA)
[ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.... ]
Christian von Kutzleben commented on JBTM-1702:
-----------------------------------------------
Hi Tom,
please see my second post from yesterday: we created a test case, that provokes RMFAIL or RB* in xa_end or xa_commit:
As you say, it's not a problem with xa_end: RMFAIL and RB* both result in a EJBTransactionRolledbackException (with EAP 6.2.4)
What our customer encountered is a slight variation: the xa_end did not raise an exception, but the subsequent xa_commit (1phase opt) did, and
here the exception gets swallowed if it was an RMFAIL.
Of course that transaction outcome is unknown and has to be handled by the user. It can't be handled by JBoss recovery (because the transaction is not prepared, it can't be reported to the JBoss recovery system). If the transaction was not committed, it will be handled by the recovery system of the resource (here: our database server).
What we expect is an EJBException (not EJBTransactionRolledbackException) that signals the user, that something went wrong and the transaction
outcome in unclear.
> one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
> -------------------------------------------------------------------------------------------------
>
> Key: JBTM-1702
> URL: https://issues.jboss.org/browse/JBTM-1702
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Transaction Core
> Affects Versions: 5.0.0.M2
> Reporter: Christian von Kutzleben
> Assignee: Tom Jenkinson
> Fix For: 4.17.18, 5.0.2
>
> Attachments: JTATest.java
>
>
> We provide our own XAResource implementation for our database product,
> in our unit testsuite we do also test common error conditions.
> The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback.
> The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure.
> The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored.
> This error occurs if and only if the one-phase optimization is used, i.e. if
> exactly one XAResource instance is enlisted with the TransactionManager.
> If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully.
> The broken logic is contained in here (also see a complete stack trace below):
> com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
> Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes.
> FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure.
> This is the complete stacktrace of our exception (logged immediately prior before it was thrown):
> About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
> com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
> at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553)
> at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54)
> at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception
> 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:92)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1702:
-------------------------------------
Also, for RMFAIL with JTS the OTS specification comes into play here and it means that we are unable to return the RolledbackException. If you look in OTS TRANS 1.4 you can see the interface for org.omg.CosTransactions.ResourceOperations::commit_one_phase() throws org.omg.CosTransactions.HeuristicHazard which means that the xa_end we do because the resource has not been delisted manually results in a CORBA UNKNOWN which the parent coordinator has to interpret as ambiguous and to be resolved by the recovery system.
> one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
> -------------------------------------------------------------------------------------------------
>
> Key: JBTM-1702
> URL: https://issues.jboss.org/browse/JBTM-1702
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Transaction Core
> Affects Versions: 5.0.0.M2
> Reporter: Christian von Kutzleben
> Assignee: Tom Jenkinson
> Fix For: 4.17.18, 5.0.2
>
> Attachments: JTATest.java
>
>
> We provide our own XAResource implementation for our database product,
> in our unit testsuite we do also test common error conditions.
> The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback.
> The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure.
> The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored.
> This error occurs if and only if the one-phase optimization is used, i.e. if
> exactly one XAResource instance is enlisted with the TransactionManager.
> If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully.
> The broken logic is contained in here (also see a complete stack trace below):
> com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
> Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes.
> FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure.
> This is the complete stacktrace of our exception (logged immediately prior before it was thrown):
> About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
> com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
> at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553)
> at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54)
> at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception
> 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:92)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1702:
--------------------------------
Attachment: JTATest.java
> one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
> -------------------------------------------------------------------------------------------------
>
> Key: JBTM-1702
> URL: https://issues.jboss.org/browse/JBTM-1702
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Transaction Core
> Affects Versions: 5.0.0.M2
> Reporter: Christian von Kutzleben
> Assignee: Tom Jenkinson
> Fix For: 4.17.18, 5.0.2
>
> Attachments: JTATest.java
>
>
> We provide our own XAResource implementation for our database product,
> in our unit testsuite we do also test common error conditions.
> The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback.
> The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure.
> The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored.
> This error occurs if and only if the one-phase optimization is used, i.e. if
> exactly one XAResource instance is enlisted with the TransactionManager.
> If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully.
> The broken logic is contained in here (also see a complete stack trace below):
> com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
> Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes.
> FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure.
> This is the complete stacktrace of our exception (logged immediately prior before it was thrown):
> About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
> com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
> at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553)
> at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54)
> at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception
> 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:92)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1702:
-------------------------------------
Hi Christian, we discussed this quite a while ago now. Please can you confirm with a small JTATest what you are saying does not work? As a "starter for 10" I have attached a small (none-JTS) example that shows you get a rollbackexception if xa_end returns RMFAIL. Please amend the test to the error codes you want and share back. BTW - It will be best for you to create a discussion on the forum rather than try to discuss it in the comments of this Jira until we get to the bottom of it.
> one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
> -------------------------------------------------------------------------------------------------
>
> Key: JBTM-1702
> URL: https://issues.jboss.org/browse/JBTM-1702
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Transaction Core
> Affects Versions: 5.0.0.M2
> Reporter: Christian von Kutzleben
> Assignee: Tom Jenkinson
> Fix For: 4.17.18, 5.0.2
>
>
> We provide our own XAResource implementation for our database product,
> in our unit testsuite we do also test common error conditions.
> The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback.
> The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure.
> The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored.
> This error occurs if and only if the one-phase optimization is used, i.e. if
> exactly one XAResource instance is enlisted with the TransactionManager.
> If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully.
> The broken logic is contained in here (also see a complete stack trace below):
> com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
> Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes.
> FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure.
> This is the complete stacktrace of our exception (logged immediately prior before it was thrown):
> About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
> com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
> at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553)
> at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54)
> at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception
> 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:92)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
by Christian von Kutzleben (JIRA)
[ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.... ]
Christian von Kutzleben edited comment on JBTM-1702 at 6/18/15 8:24 AM:
------------------------------------------------------------------------
-
was (Author: cvk):
see comment
> one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
> -------------------------------------------------------------------------------------------------
>
> Key: JBTM-1702
> URL: https://issues.jboss.org/browse/JBTM-1702
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Transaction Core
> Affects Versions: 5.0.0.M2
> Reporter: Christian von Kutzleben
> Assignee: Tom Jenkinson
> Fix For: 4.17.18, 5.0.2
>
>
> We provide our own XAResource implementation for our database product,
> in our unit testsuite we do also test common error conditions.
> The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback.
> The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure.
> The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored.
> This error occurs if and only if the one-phase optimization is used, i.e. if
> exactly one XAResource instance is enlisted with the TransactionManager.
> If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully.
> The broken logic is contained in here (also see a complete stack trace below):
> com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
> Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes.
> FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure.
> This is the complete stacktrace of our exception (logged immediately prior before it was thrown):
> About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
> com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
> at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553)
> at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54)
> at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception
> 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:92)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months