geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandip Ghayal <>
Date Sat, 26 Feb 2005 21:06:33 GMT
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

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

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


Sandip Ghayal

--- Jeremy Boynes <> wrote:

>  From IRC last night
> <dain> djencks: can a Transaction object return
> <djencks> right now, ours do but I believe that is
> an error
> <djencks> I think after they are complete they
> should be 
>  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 

View raw message