In previous releases of JBoss EAP 6, if the server crashed during an XA transaction, the XA resource did not always roll back immediately.
This issue has been corrected by an upgrade of `org.jboss.jbossts`. Transactions now roll back and logs are cleaned as expected.
The issue points to the fact that crash at the true end of the prepare phase of the 2PC could cause that CMR resource will be rollbacked (or marked as to be rollback - there is in fact no rollback called as CMR is standard non XA resource) but rest of the XA resources (which are participant of the transaction) won't be rollback and stay at in-doubt state.
This will be up to time when orphan detection would kick in.
1) enlist test XA Resource
2) enlist CMR resource
3) prepare CMR resource (nothing is written to xids table)
4) prepare test XA resource
5) finish 2PC prepare phase by writing everything to log
6) crash JVM of app server
7) recover - rollback for all resouces (CMR and XA) is expected but XA resources are left in in-doubt state
I reworded this a bit. Please let me know if this sounds okay:
In this release of JBoss EAP 6, if the server crashes at the end of the prepare phase of a two-phase commit when Commit Markable Resource is part of the XA transaction, the XA resource does not roll back as expected. The resources remain in that state until such time when orphan detection is started.
This issue is expected to be resolved in a future release of the product.
Ondra review and responded on IRC. Replacing the doc text and setting the flag.
I think we should change it to "XA resource does not roll back immediately as expected" - note the addition of "immediately".
It will rollback, its qualified in the next sentence when that will be.
Thanks Tom. I think it may also need a comma.
Changed it to "the XA resource does not roll back immediately, as expected."
Tom Jenkinson <email@example.com> updated the status of jira JBTM-2229 to Closed
Setting to MODIFIED. Should be fixed by upgrade org.jboss.jbossts to 4.17.22.Final-redhat-2. https://bugzilla.redhat.com/show_bug.cgi?id=1129524
Now transaction is rolled-back and Tx logs are clean.
Verified on revision 6.4.0 DR2