[jbossts-issues] [JBoss JIRA] (JBTM-1865) Transaction reported to be rolled back, although committed with one participant

[Mark Little (JIRA)]

    [ https://issues.jboss.org/browse/JBTM-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794170#comment-12794170 ] 

Mark Little commented on JBTM-1865:
-----------------------------------

"It's 2PC and the XAResource has already guaranteed to commit the transaction." If we lived in the world of the strict 2PC protocol then you would be right. However, no transaction manager standard or implementation since the 1960's has been able to live in that world, since strict 2PC is a blocking protocol. As a result, heuristics were introduced and any resource that has prepared can still go back on that choice between prepare and being told what to do by the coordinator. The only thing it has to do is remember this autonomous decision so it can report it to the coordinator eventually.

This is all documented at length in various standards and books. We also have quite a few articles and videos on the JBoss.org site as well as in the JBoss transactions team's blog. I recommend you check them out if you need further clarification.
                
> 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