geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Date Sun, 27 Feb 2005 00:48:03 GMT
Sandip Ghayal wrote:
> 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

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 
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

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.


View raw message