I think I may have tracked down the SwiftMQ bug... let me know if this sounds right.
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. 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
3.1.diff
Description: Binary data
