From IRC last night
<dain> djencks: can a Transaction object return status NO_TRANSACTION?
<djencks> right now, ours do but I believe that is an error
<djencks> I think after they are complete they should be STATUS_COMMITTED or STATUS_ROLLED_BACK
From the JavaDoc for Transaction.getStatus():
Returns:
The transaction status. If no transaction is associated with the target object, this method returns the Status.NoTransaction value.
So yes, it definitely can, and code that is using Transaction needs to be able to handle that even if our particular implementation does not allow it.
From the JTA spec 3.2.2, once a TransactionManager.commit() or rollback() method completes the thread is not associated with a transaction. However, 3.3.3 does not imply that the transaction is dissociated if commit/rollback is done via the Transaction interface.
I read this as saying: * if you commit/rollback using the TM, then the thread association is broken and TM.getStatus() returns NO_TRANSACTION * if you commit/rollback using the TX, then the thread association is unchanged and TM.getStatus() returns the Transaction's status
This does seem to raise the problem of how to dissociate a transaction from the thread once a commit/rollback has been completed on the TX itself. However, from 3.2.3 it seems calling TM.suspend() is sufficient.
We do not support nested transactions, so as defined by 3.2.1 any attempt to start a transaction when there is one already associated with the thread must result in a NotSupportedException; this would apply even if that transaction has completed.
It looks to me that the code in TransactionImpl that sets the status to NO_TRANSACTION on completion is not needed and should be removed. This will also mean that anything that completes a transaction using the Transaction instance must ensure that it is not associated with a thread; this may affect timeouts.
-- Jeremy
