Hmmm. I do not understand you either. I have certainly read the XA spec, but - of course - am not entirely sure that my implementation is free of errors.
Active and suspended contexts are of course shared by the XA resource, why should it be local to a thread then? Maybe the misunderstanding is the active transaction branch which is associated to a specific thread. That's why it is a thread local. This means if there is a tx associated to a thead it will be stored there. Oliver 2005/11/17, Joerg Heinicke <[EMAIL PROTECTED]>: > Oliver Zeigermann <oliver.zeigermann <at> gmail.com> 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. > > Regards, > > Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
