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. 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. 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 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) 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. Cheers, Sandip Ghayal --- Jeremy Boynes <[EMAIL PROTECTED]> wrote: > 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 > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
