TM: END signal sent to XAResource before COMMIT

[sanepid]

For a XA transaction where multiple external resources are involved, each XAResource implmentation will get an END from the TM when the connection is closed. But the same XAResource will receive another END before COMMIT even if the resource has been already delisted. Is there any way for TransactionImpl to check whether the registered XAResource has already got the END in order to avoid END redundancy? This may be implemented at the RM level as well, but treated in the TransactionImpl, would eliminate additional overhead. The JCA specification mentions that the TM should send the END before COMMIT, but it doesn't say anything about additional checking in this matter.

I use JBoss 3.0.1

Thanks
Radu

[davidjencks]

There may be some bugs in this area, and the jta spec may not be able to do what it seems to offer. The problem as I see it is that for work in one transaction on one connection, you need a series of calls like this:

start -- noflags

end -- suspend

start -- resume

end-- suspend

start -- resume

end -- success

and then you can commit. The problem IMO is that in an app server environment, you don't know when the end of the tx will occur until you actually commit, whereas usually connections are acquired and released many times within the tx. So, if you release the connection with an end when the cx handle is closed, you would need knowledge of the future (is this really the end of the tx?) to decide to call end -- success rather than end -- suspend.

We could tie the connection and xaresource to the transaction, but then we'd lose the ability to run several transactions over the same connection, one of the main advantages of xa over local tx. We _might_ be able to tie a connection/xaresource to a thread, and only call the start/end when the tx actually changes (such as with a call to a RequiresNew method), but then we'd basically need one connection per thread in the server.

I am rapidly coming to the conclusion that, due to problems like this, jta is not an appropriate transaction model for a modern app server.

You might also look at the discussion on bug 590816