Re: [transaction] AbstractXAResource throws exception on TMJOIN
Oliver Zeigermann oliver.zeigermann at gmail.com writes: But even more, may understanding is that the user will never see an XAResource and will never try to get an instance of it. It simply is an interface between the transaction manager of your container and your resource manager. Ok, this might be the reason for my different views up to now. Is an XAResource always supposed to be accessed through JCA, i.e. the resource adapter is an implementation of JCA? I got the impression when having again a look on your transactional Map implementation. Unfortunately the JTA spec does not speak about this point (JCA), only mentions JDBC and JMS, which might be an analogy here. Yet another spec/API I have to look at ... and maybe the JTA spec makes more sense with this changed view. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transaction] AbstractXAResource throws exception on TMJOIN
Hello, 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. From the implementation of the start method I assume TMJOIN implementation is included, but wrong. For joining an active transaction also createTransactionResource() is called while probably getActiveTransactionalResource(Xid xid) would be correct. WDYT? Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] AbstractXAResource throws exception on TMJOIN
2005/11/17, Joerg Heinicke [EMAIL PROTECTED]: 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. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] AbstractXAResource throws exception on TMJOIN
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]
Re: [transaction] AbstractXAResource throws exception on TMJOIN
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]
Re: [transaction] AbstractXAResource throws exception on TMJOIN
Oliver Zeigermann oliver.zeigermann at gmail.com writes: 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. I did not know that it was you implementing it. And about the errors: that's what I want to find out. Interpreting the spec is not that easy IMO, it is really database specific and talks about connection's close method: Huh? Is it about JTA or JDBC? Where is a connection in JTA. Active and suspended contexts are of course shared by the XA resource, why should it be local to a thread then? My problem is that the contexts are specific to an XAResource *instance*. But is it not possible to have more than one instance accessing one resource manager from one thread? This is what my example with the two components was about. If you use JNDI (standard in EJB 2.x) for looking up your XAResource you get a new instance of XAResource for each lookup, so one for both components. This is why I think the contexts must be made known to the thread (hence ThreadLocal), not only to the instance. 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. No I think, that is clear. It is only difficult to control if you allow multiple XAResource instances per thread - which is allowed from my understanding. Hope it's getting clearer where my actual problem is. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
