[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,
A small update from our tests (JTA, a single resource only):
Actually, if we provoke XA_RB* or XA_RMFAIL in end(), the bean caller *will* receive an EJBTransactionRolledbackException.
(so you're correct, that it is fixed for both)
If we let end() succeed and provoke XA_RB* or XA_RMFAIL in commit(), then the bean will receive an EJBTransactionRolledbackException
if it was XA_RB*, but the error is swallowed if XA_RMFAIL is thrown (expected: EJBException).
The argument why this is wrong is the same as for end() -- I'll reopen the issue, because it's
conceptually the same error as with end() (and I think the JTS fix was also tracked under this here)
Best regards,
Christian
> 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 reopened JBTM-1702:
-------------------------------------------
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
[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,
There is currently some ongoing discussion between one of our customers and JBoss Support regarding this behavior:
I was under the impression, based on your statement from March, 3rd 2014, that this was fixed for XA_RB* as well as
XA_RMFAIL, could you please clarify?
Our position is, that it is a bug to not return an exception to the client, if the resource manager returns XA_RMFAIL to an
1-phase commit invocation. (I'll search for the respective statements in the EJB 3.0 spec that mandate/imply this later, in case
that you have a different position.)
Of course it can't return an EJBTransactionRolledbackException in this particular case, as the transaction status is unknown,
but a generic EJBTransaction containing the message, that the transaction outcome is unclear would be just fine.
In this case user interaction is required anyways, because JBoss recovery could never handle such a transaction, because
it has never reached the "Prepare" state.
Best regards,
Christian
> 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-2435) Generated documentation doesn't render in Internet Explorer 8
by Jaromir Hamala (JIRA)
[ https://issues.jboss.org/browse/JBTM-2435?page=com.atlassian.jira.plugin.... ]
Jaromir Hamala commented on JBTM-2435:
--------------------------------------
Hello Tom,
Thank you for looking into this. I don't really have IE to my disposal at this moment.
When I was reporting this issue 2 years ago I was doing on-site consultancy gig for a customer where IE8 was the allowed browser allowed :-( Sadly it wasn't that uncommon rule for some organizations back then. I though you'd like to know your documentation wasn't usable in these environments.
Hopefully silly rules regarding browsers are less common by now or at least the favour newer & more sane browsers now:))
Cheers,
Jaromir
> Generated documentation doesn't render in Internet Explorer 8
> --------------------------------------------------------------
>
> Key: JBTM-2435
> URL: https://issues.jboss.org/browse/JBTM-2435
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Environment: WinXP, Internet Exporer 8
> Reporter: Jaromir Hamala
> Attachments: jboss_docs_ie_bug.png
>
>
> Hi,
> I noticed documentation at docs.jboss.org doesn't render properly in IE8.
> How to reproduce it:
> Open this URL in IE8: http://docs.jboss.org/jbosstm/4.17.3.Final/guides/failure_recovery_guide/
> Expected behaviour:
> Documentation should be rendered
> Current behavour:
> Document is not rendered
> I noticed it's affecting multiple pages, not just this one. Therefore I assume there is a bug in a DocBook template.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (JBTM-2398) Support VolatileStore.allObjUids
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2398?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on JBTM-2398:
----------------------------------------
I ran a benchmark using the two new stores and there is a big difference (300%) when running a workload using multiple threads and there is a 30% difference with one thread. These differences warrant introducing new subclasses. The 3 fold difference with the TypedVolatileStore test makes no sense but is definitely consistent:
-i 1 -wi 10 -f 1 -t 10 -r 100 # 10 warm up iterations and then a single iteration lasting 100 seconds using 10 threads
c.a.a.j.x.p.VolatileStoreBenchmark.testVolatileStore thrpt 1 639773.579 NaN ops/s
c.a.a.j.x.p.TypedVolatileStoreBenchmark.testVolatileStore thrpt 1 183711.939 NaN ops/s
c.a.a.j.x.p.TwoPhaseVolatileStoreBenchmark.testVolatileStore thrpt 1 151985.542 NaN ops/s
c.a.a.j.x.p.TypedTwoPhaseVolatileStoreBenchmark.testVolatileStore thrpt 1 103152.792 NaN ops/s
-i 1 -wi 10 -f 1 -t 1 -r 100 # 10 warm up iterations and then a single iteration lasting 100 seconds using 1 thread
c.a.a.j.x.p.VolatileStoreBenchmark.testVolatileStore thrpt 1 191072.127 NaN ops/s
c.a.a.j.x.p.TypedVolatileStoreBenchmark.testVolatileStore thrpt 1 142127.089 NaN ops/s
c.a.a.j.x.p.TwoPhaseVolatileStoreBenchmark.testVolatileStore thrpt 1 137941.989 NaN ops/s
c.a.a.j.x.p.TypedTwoPhaseVolatileStoreBenchmark.testVolatileStore thrpt 1 114109.209 NaN ops/s
> Support VolatileStore.allObjUids
> ---------------------------------
>
> Key: JBTM-2398
> URL: https://issues.jboss.org/browse/JBTM-2398
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: Performance Testing
> Affects Versions: 5.1.1
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Optional
> Fix For: 5.later
>
>
> This method is used by REST-AT and would be a useful addition for baselining the performance of the coordinator for comparison with non transactional and empty transaction requests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (JBTM-2428) JTS client side transaction context seems not being propagated to EAP server
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2428?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka commented on JBTM-2428:
----------------------------------------
yes, I forgot to mention it. As this settings was working with jacorb it's still in our repo. But for my testing I've been experimenting with removing those values and changing it to some possible jdk orb alternatives. But to be honest I don't what could be the correct settings.
> JTS client side transaction context seems not being propagated to EAP server
> ----------------------------------------------------------------------------
>
> Key: JBTM-2428
> URL: https://issues.jboss.org/browse/JBTM-2428
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Affects Versions: 5.1.1
> Reporter: Ondřej Chaloupka
> Assignee: Tomasz Adamski
>
> It seems that transaction context is not propagated when JTS transaction is started on client.
> This was working for EAP 6.4 where iiop corba implementation was used. The testing client is based on guide [1].
> The call from client to server via IIOP [4] works fine but when I'm trying to start transaction on client side and then expecting being propagated to server, server proclaims that there is no txn in the context.
> This is how the orb is set up [2]
> This is how the transaction is started [3]
> This is how the remote call on ejb app server is done [4]
> [1] https://developer.jboss.org/wiki/TransactionPropagationWithJBoss
> [2] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-tra...
> [3] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-tra...
> [4] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-tra...
> [5] [com.arjuna.ats.jts] (main) ARJUNA022251: The ORBManager is already associated with an ORB/OA.
> FINE [javax.enterprise.resource.corba._DEFAULT_.rpc.protocol] (main) "IOP01600014: (BAD_INV_ORDER) Cannot access this attribute or method at this point": org.omg.CORBA.BAD_INV_ORDER: vmcid: OMG minor code: 14 completed: No
> -- or --
> FINE [javax.enterprise.resource.corba._CORBA_.rpc.presentation] (main) "IOP00110227: (BAD_PARAM) ORBDynamicStubFactoryFactoryClass property had value com.sun.corba.se.impl.presentation.rmi.bcel.StubFactoryFactoryBCELImpl, which could not be loaded by the ORB ClassLoader": org.omg.CORBA.BAD_PARAM: vmcid: SUN minor code: 227 completed: No
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months