My Two cents on this
I am referring to specs version JTA-1_0_1B
My interpretition is that section 3.2.2 and section 3.3.3 are referring to different scenarios.
3.2.2. is where the transaction is associated with the thread whereas 3.3.3 is referring to scenarios when transaction is not associated with the thread.
I'd phrase that slightly differently and say that 3.2 describes interactions through the TransactionManager whereas 3.3 describes interactions through a Transaction object. There is an interaction between them depending on whether a Transaction object is associated with the thread or not.
In detail 3.2.2 refers to scenarios where the
transaction is associated with currently running
object (could be an EJB). In those scenarios after
commit call is made transaction should be
disassociated from the thread.
I don't think the object (EJB) matters - 3.2.2 is describing transaction completion performed through the TransactionManager with the implicit assumption that the transaction being completed is the one associated with the thread. It defines the semantic here as saying that once the method returns then the thread will not be associated with a transaction (an alternative definition could have been that the transaction remained associated with the thread in a COMMITTED/ROLLEDBACK state and would have to be explicitly dissociated). However, it does not say exactly when the dissociation occurs.
Section 3.3.3 refers to scenarios where client started the transaction. Currently no thread on the server is associated with the transaction. Actual transaction is in suspended state, with no association. As transaction is not associated with the thread, one does not need to disassociate the transaction from the thread
That may be the typical case but 3.3.3 does not require that the transaction be suspended. It could have done that by requiring that it be associated with the current thread (which implicitly means it cannot be associated with another) but instead explicitly allows it not to be (and by implication allows it to be associated with another).
Now regarding STATUS.STATUS_NO_TRANSACTION my take is After transaction has been commited/rollback on the thread that is associated with transaction and getStatus() call is made to TransactionManager one should get STATUS.NoTransaction. But if you have access to transaction Object (TransactionManager.getTransaction()) and after commit (or rollback) one does getStatus on this object then we need to return back STATUS.STATUS_COMMITTED (or STATUS.STATUS_ROLLBACK)
I think we have a window where the transaction associated with the current thread gets committed/rolled-back directly by a different thread; a call to TransactionManager.getStatus() on the current thread should return the status of the associated transaction which will be COMMITTED or ROLLED_BACK and not NO_TRANSACTION. It is then the responsibility of the current thread to explicitly dissociate the transaction from the thread by calling TM.suspend().
Also one more caution, after commit method returns back there should not be any transaction associated with the thread. i.e. if the call is made during afterCompletion stage for getStatus it should return back STATUS_NO_TRANSACTION.
I'm not so sure here. Assuming the transaction was completed using the TransactionManager (3.2.2) then afterCompletion will be called before the commit/rollback method returns. I could not find where the spec defines if the transaction is still associated with the current thread at this time or not and so would consider the result of TM.getTransaction() and TM.getStatus() to be undefined.
On the other hand, is does specify that a call to getStatus (and given context I assume this means TX.getStatus()) returns the same as the status parameter passed in and hence can only be COMMITTED or ROLLEDBACK and not NO_TRANSACTION. It does not matter if the completion was initiated using the TM or the TX directly.
These factors determine the result of TM.getStatus(): if the TM has already dissociated the transaction then the result is obviously NO_TRANSACTION, but if it has not then it should be that returned by getStatus() on the still associated transaction.
Of course, this ambiguity is predicated on the spec being unclear on when the transaction is actually dissociated; if we can clear that up then everything else falls out.
Our current implementation goes one step beyond and once all afterCompletion callbacks have been made sets the status to NO_TRANSACTION. I originally did this so we could tell that all callbacks had been done. However, as I said in the previous mail I don't think we really need to know that; it may actually be confusing.
-- Jeremy
