commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: [transaction] AbstractXAResource throws exception on TMJOIN
Date Thu, 17 Nov 2005 12:54:31 GMT
Oliver Zeigermann <oliver.zeigermann <at>> writes:

> > there seems to be some inconsistency in the implementation of
> > AbstractXAResource regarding TMJOIN in the start() method. The first thing
> > that is checked for in this method is
> > "getCurrentlyActiveTransactionalResource() != null" and a XAException is
> > thrown if there is a currently active transactional resource (CATR). But IMO 
> > this is wrong for TMJOIN as you want to join a transaction, so
> > there must be a CATR.
> A thread can only be part of at most one transaction at a time. If it
> already has an active transaction, joining another is an invalid
> operation.

Sorry, but I don't understand you here. If a thread can only have one
transaction, why is it not allowed to join this active one?

But re-reading the spec I came to the conclusion that the "CATR != null" check
is not the problem. In section 3.4.4 of the spec (you know it?) there is a table
about the correct XAResource to transaction association. And for both
start(NOFLAGS) and start(TMJOIN) the XAResource can only switch from "not
associated" to "associated" meaning that the null check is ok.

But as far as I understand the spec there can be multiple instances of
XAResource accessing the same resource manager (otherwise TMJOIN makes no sense,
and XAResource.isSameRM(XAResource) neither).
Example: Both component1 and component2 have a method requiring a transaction,
and component1 calls component2. Both lookup the same XAResource from JNDI
actually getting different instances of this XAResource. When component2 now
accesses the XAResource it actually *joins* the transaction.

This means that another aspect of AbstractXAResource is wrong: I already
mentioned createTransactionResource(Xid) for TMJOIN in the last mail. IMO it
must be getActiveTransactionalResource(Xid). This leads to another change to get
it working as the activeContexts would be empty of course: The both maps
suspendedContexts and activeContexts must be static ThreadLocal variables.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message