-
15. Re: Why does com.arjuna.ats.internal.jts.orbspecific.coordinator.ArjunaTransactionImple throw INVALID or Inactive when we know the status is ABORTED?
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.
-
16. Re: Why does com.arjuna.ats.internal.jts.orbspecific.coordinator.ArjunaTransactionImple throw INVALID or Inactive when we know the status is ABORTED?
I looked back through the history and we made the change for JBTM-476 in order to handle reaped remote transactions more gracefully:
r24872 | mark.little@jboss.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:
- ControlWrapper#rollback: On receipt of an NPE (from _controlImpl.getImplHandle().rollback()) we used to throw TRANSACTION_ROLLEDBACK exception since the handle has gone. But that is equivalent to telling the caller that the rollback has happened so a return is just as good. As an aside (as in not relevant to the bug fix), according to the OTS spec it is not valid to throw TRANSACTION_ROLLEDBACK here;
- ArjunaTransactionImple#rollback: If status is one of {ABORTING, ABORTED, H_ROLLBACK) we return instead of throwing INVALID_TRANSACTION. This seems reasonable since the transaction is not invalid.
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).
-
17. Re: Why does com.arjuna.ats.internal.jts.orbspecific.coordinator.ArjunaTransactionImple throw INVALID or Inactive when we know the status is ABORTED?
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