I have finally downloaded and tested this patch with SwiftMQ, and it does indeed fix the problem. Does anyone object if I go forward with this patch? (Note - I simplified it a bit, and added some (too much?) commenting).
-Larry > I think I may have tracked down the SwiftMQ bug... let me know if this > sounds right. > > SwiftMQ doesn't support start(join), 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. > > 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?). > > Basically, we can't assume that (resource1 == resource2) implies > (resource1.isSameRM(resource2)). > > 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. > > 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. > > -Larry >
3.0.diff
Description: Binary data
