First the apology: anonymous wrote : Configuration/deployment of the connection manager/pool isn't even in the jca spec so how can it be a compliance issue?
The deployment/configuration of a connection manager/pool was never an issue, I simply misunderstood what the track-connection-by-tx attribute did. So, sorry about the earlier statement about not being compliant with the JCA specification, it does provided the expected behavior. anonymous wrote : You didn't need to dump the logging, I know exactly how it works. :-) Did not know. anonymous wrote : The MC only has to maintain a one-one relationship with the *active* XAResource, | that is why TM_SUSPEND exists. Do you mean the current transaction context and not the XAResource? The JCA specification states the relationship should be with the same XAResource not the active XAResource. Section 6.3.2 of the JCA specification states the following: A resource adapter is responsible for maintaining a 1-1 relationship between the ManagedConnection and XAResource instances. Each time a ManagedConnection.getXAResource method is called, the same XAResource instance has to be returned. anonymous wrote : JBossMQ handles transaction interleaving quite effectively, it allows fewer | connections to be used for the same number of transactions. I do not have a problem with transaction interleaving, but with the branchÂs transaction association and when the MC is placed in the connection pool. In the example I presented, the association between the MC and the current transaction context is only suspended. Thus, a new transaction context cannot be associated with the XAResource. From section 3.4.4 of the JTA specification, it states the following: Global transactions are associated with a transactional resource via the XAResource.start method, and disassociated from the resource via the XAResource.end method. The resource adapter is responsible for internally maintaining an association between the resource connection object and the XAResource object. At any given time, a connection is associated with a single transaction or it is not associated with any transaction at all. The last sentence is key, because in my example the XAResource.end(TMSUCCESS) call has not returned before the second client comes along - thus the transaction association is still in a suspended state; Table 1 - Transaction Association of the JTA specification shows that XAResource.start() cannot be called on a branch whose transaction association has been suspended. XAResource.start(TMRESUME|TMJOIN) may be called on a branch whose transaction association has been suspended, but returning the MC to the pool implies that MC is not associated with any transaction - I would expect XAResource.end(TMSUCCESS) to be invoked before the MC is returned to the connection pool. I am probably missing a step somewhere, I would like to take advantage of JBOSS's transaction interleaving implementation, but I have concerns with transaction association, who is doing work on what transaction, and compatibility issues with other application server. Basically, I need to do more testing. Anyway, the track-connection-by-tx attribute provides what I need. Thanks for your time it is much appreciated. Now, if we only had recovery... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3842640#3842640 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3842640 ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
