Larry Sandereson wrote: > I think I may have tracked down the SwiftMQ bug... let me know if this > sounds right.
This is great. And it sounds right to me. > SwiftMQ doesn't support start(suspend), so they return false for all calls > to isSameRM(). This should cause all connections being enlisted to be given > a unique xid (with different branch qualifiers). I think this is compliant > with the JTA and XA specs. start(suspend) doesn't make sense to me. Do you mean end(suspend), start(resume) or start(join)? So SwiftMQ doesn't support something it ought to for JTA compliance... And to get around that, it does something truly wierd. This may in some cases be heavy performance-wise, since there may be a lot of "=="-equal resources enlisted with the TM. I have heard that some application servers in some cases delist before every call to another bean, and enlist again afterwards (that way the other bean can use the same connection, even if in another tx). Have you checked if this is listed as a bug in SwiftMQ? > In enlistResource (TransactionImpl:535), a check is made to see if this RM > is already enlisted (call to findResource). But, this check uses an > equality test. If you are enlisting a connection that was previously closed > in the same transcation scope, then this will find the old resource, and > attempt to re-enlist with a TMJOIN, which on SwiftMQ yields an XAException > (PROTO?). Ahh, so it is start(join) that SwiftMQ does not support. > Basically, we can't assume that (resource1 == resource2) implies > (resource1.isSameRM(resource2)). Ouch. I have been assuming this, but when rereading the JTA specification, I see nowhere that we can assume this. JTA really ought to explicitly state if such an assumption can be made, or it will be a source of implementation errors. > The problem now is that the TM must be able to enlist the same resource > multiple times with different branch-ids, and then figure out which xid to > use on the next call to delist. Agreed. > I have attached a patch (one for JBoss 3.1 one for JBoss 3.0) that I think > fixes the problem. Please let me know what you think. I just had a quick look at the 3.1 patch, and it looks fine to me. I have a question though: Why also check for RS_ENDED state? And a comment: In delist, probably an exception should not be thrown. False should be returned instead, and IMHO the exception at line 451 should also be changed to returning false. But still I wonder: What happens if several SwiftMQ "=="-equal resources are enlisted in the same transaction. How do we ensure that it is the right resource that we call end() on? After all, we do not get the Xid supplied to the delist call, so we really have no way of knowing which Xid to end when the resources are "=="-equal. Best Regards, Ole Husgaard. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
