Mike, see the comment I just added to the JIRA. Would be important to check the history of the code changes in this area. For instance, in earlier versions we threw Unavailable and not TRANSACTION_ROLLEDBACK.
I looked back through the history and we made the change for JBTM-476 in order to handle reaped remote transactions more gracefully:
r24872 | email@example.com | 2009-01-22 13:34:56 +0000 (Thu, 22 Jan 2009) | 1 line
The only code changes that we (Tomasz and myself) made on this new JIRA (JBTM-2725 Race condition in ControlWrapper) were:
I would argue that our change does not negatively impact the fix for JBTM-476 since we are still handling rolled back transactions gracefully (ie returning from the call instead of throwing any kind of exception since transaction has rolled back which is what the caller asked for).
OK thanks for checking where the change from Unavailable to TRANSACTION_ROLLEDBACK occurred. I agree with your assessment, with the exception that TRANSACTION_ROLLEDBACK can be thrown from rollback because ControlWrapper isn't part of the OTS standard - it's a Narayana specific implementation. Now although it tries to look and behave like a Control and its sub-interfaces such as Terminator and Coordinator, it doesn't mimic them perfectly. Plus, Terminator::rollback can throw any system exception, including TRANSACTION_ROLLEDBACK, unless explicitly stated otherwise in the standard. And at least in OTS 1.4 it doesn't preclude