XA PROTOCOL OPTIMIZATIONS

While there currently exist a number of optimizations in the XA transaction spec

ification and implementations that mitigate the need for one or more communicati
on calls in the XA exchange (such as one-phase commit), this abstract describes
some that do not yet exist.
A global/XA transaction application generally has the following form in Java:
1. userTransaction.begin() // A global transaction is demarcated using JTA
2. connection1.prepareStatement().execute(); // Work is conducted on a resource
manager such as a database
3. connection2.prepareStatement().execute(); // Work is conducted on another re
source manager such as a database
4. userTransaction.commit(); // A global transaction is completed/committed u
sing JTA
In reaction to the userTransaction.commit call the application server must make
XAResource.end calls on all the resource managers involved in the transaction be
fore it conducts two-phase commit where two-phase commit involves the applicatio
n server first calling XAResource.prepare on all the resource managers involved
in a transaction and then (provided all resource managers reply with an XA_OK vo
te) calling XAResource.commit on all resources involved in a transaction.
This abstract proposes an optimization to this pattern (which has been in existe
nce for decades) by combining the XAResource.end and XAResource.prepare calls in
to one network call thus eliminating an entire network call for each resource in
each transaction using the following logic and procedure:
1. When XAResource.end is called by the application server it is done with a sp
ecial DEFERRED flag rather than the TMSUCCESS flag used currently. This call si
mply sets a flag locally and does not make a remote call.
2. When XAResource.prepare is called by the application server the database rec
eives the request and conducts the necessary work that would have resulted from
an explicit XAResource.end call and then conducts the XAResource.prepare.
3. Both XAResource.end and XAResource.prepare throw XAExceptions, however, diff
erent error codes can be thrown for each. The application server will inspect a
ny XAException error codes and process appropriately just as it does today.
4. A further optimization occurs in the case where it is known by the applicati
on server that there is only one XAResource in a transaction or when all of the
XAResource.prepare calls from all but the last XAResource to be prepared have re
turned a vote of XA_RDONLY. In this case there is no need call XAResource.prepa
re on the only (or only remaining) XAResource and so the application server forg
oes calling XAResource.prepare on that resource and the XAResource.end call is d
iffered until the XAResource.commit.
Further, in reaction to the userTransaction.commit call the application server m
ust make XAResource.end calls on all the resource managers involved in the trans
action before it conducts two-phase commit where two-phase commit involves the a
pplication server first calling XAResource.prepare on all the resource managers
involved in a transaction and then (provided all resource managers reply with an
XA_OK vote) calling XAResource.commit on all resources involved in a transactio
n.
This abstract proposes an optimization to this pattern (which has been in existe
nce for decades) by combining the XAResource.end and XAResource.prepare calls in
to one network call thus eliminating an entire network call for each resource in
each transaction using the following logic and procedure:
1. When XAResource.end is called by the application server it is done with a sp

ecial DEFERRED flag rather than the TMSUCCESS flag used currently. This call si
mply sets a flag locally and does not make a remote call.
2. When XAResource.prepare is called by the application server the database rec
eives the request and conducts the necessary work that would have resulted from
an explicit XAResource.end call and then conducts the XAResource.prepare.
3. Both XAResource.end and XAResource.prepare throw XAExceptions, however, diff
erent error codes can be thrown for each. The application server will inspect a
ny XAException error codes and process appropriately just as it does today.
4. A further optimization occurs in the case where it is known by the applicati
on server that there is only one XAResource in a transaction or when all of the
XAResource.prepare calls from all but the last XAResource to be prepared have re
turned a vote of XA_RDONLY. In this case there is no need call XAResource.prepa
re on the only (or only remaining) XAResource and so the application server forg
oes calling XAResource.prepare on that resource and the XAResource.end call is d
iffered until the XAResource.commit.