geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Date Sun, 27 Feb 2005 19:00:14 GMT
Since it appears there are several valid readings of this spec, I think 
we should ask the spec commit for a clarification.  I think these are 
the two issues we need to clarify:

1) If commit or rollback is called on a Transaction object directly, 
what are the expected/allowed statuses after the call?  Specifically, 
is NO_TRANSACTION allowed?

2) If commit or rollback is called on a Transaction object that is 
associated with a thread, when is the thread disassociation 
expected/required?  What should getStatus() on the TransactionManager 
return for the associated thread?

Any other issues, we should have clarified?


On Feb 26, 2005, at 4:48 PM, Jeremy Boynes wrote:

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

View raw message