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
>

Attachment: 3.0.diff
Description: Binary data

Reply via email to