]
Mark Little commented on JBTM-2255:
-----------------------------------
Unfortunately this change is not guaranteed to work in all situations. You are assuming
that GenericRecoveryCoordinator is a local instance to the transaction manager/coordinator
but it isn't. This comes from the OTS specification and if you run through the various
ways in which the status variable can be set (at the start of the method) you'll see
that a) it can be remote from the coordinator and b) the status may even be obtained
remotely. So there's a very good chance that BasicAction information isn't
available to the GenericRecoveryCoordinator because it simply isn't in the same
process.
Do not return StatusCommiting, if transaction was commited by the
original transaction manager
----------------------------------------------------------------------------------------------
Key: JBTM-2255
URL:
https://issues.jboss.org/browse/JBTM-2255
Project: JBoss Transaction Manager
Issue Type: Bug
Components: JTS
Reporter: Gytis Trikleris
Assignee: Gytis Trikleris
Fix For: 4.17.23
We need to check if the transaction is really in flight before returning status as
committing. Previously code assumed, that if returned status is StatusCommitted, the only
reason why the resource invoked replay_completion is that the transaction is in the
process of committing.
However, as shown by the attached bugzilla, another work flow is also possible. Because
Oracle database returned XAException.XAER_RMFAIL, second resource was committed
successfully and the client was told that the transaction committed successfully. Recovery
was left to sort out the issue with the database. Once the database resource invoked
replay_completion and transaction manager saw the status of the transaction as
StatusCommitted, it assumed that it is still in action even though there is no BasicAction
available.