[
https://issues.jboss.org/browse/JBTM-1866?page=com.atlassian.jira.plugin....
]
Mark Little commented on JBTM-1866:
-----------------------------------
Christian, I also suggest you go and read the OTS specification from the OMG. Here's a
snippet:
"A heuristic decision is a unilateral decision made by one or more participants in a
transaction to commit or rollback updates without first obtaining the consensus outcome
determined by the Transaction Service. A participant can only make a heuristic decision
once the two-phase-commit protocol has begun, in particular it cannot make such a decision
if it receives a rollback without a previous prepare. Heuristic decisions are normally
made only in unusual circumstances, such as communication failures, that prevent normal
processing. When a heuristic decision is taken, there is a risk that the decision will
differ from the consensus outcome, resulting in a loss of data integrity."
And if you read all of it you will see that heuristic decisions are not necessarily just
thrown (caused) by a single RM. I've already given this example, but I'll repeat:
2 RMs in the commit list, both prepare successfully and the coordinator logs the intention
to commit; during the 2nd phase of 2PC if the 1st RM commits and the 2nd rolls back then
we have a heuristic (HeuristicMixed). A heuristic decision that is reported by the
coordinator to the client indicates that we have a non-atomic outcome.
HeuristicMixedException reported to client, although backends
don't support heuristic completion
------------------------------------------------------------------------------------------------
Key: JBTM-1866
URL:
https://issues.jboss.org/browse/JBTM-1866
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
this bug is related to:
https://issues.jboss.org/browse/JBTM-1865
While testing recovery and transaction failures we came across
two related issues, the test scenario is almost the same, the other
issue is filed as JBTM-1865
Scenario:
2 enlisted XAResources (one for each database used by the test),
The prepare phase is successful.
We crash the second 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.
The first branch was successfully committed (as it should be spec.)
But now things go awry:
1. The client receives a HeuristicMixedException, although the backend
does not support heuristic completion at all, i.e. there should be no Heuristic*
exception be thrown
The correct behavior is, to report the transaction as success to the client, commit all
other 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