Last Resource Commit Optimization (LRCO) in JBossTS JTA/JTS

There is a window of opportunity where a system could crash between the commit of a Last Resource and the log of an XID, which would result in inconsistent state of transactional resources. If a crash occurred as shown below, the last resource would remain committed, while the XA capable resources would be rolled back on recovery.

Steps:
1. Begin transaction
2. Prepare XA resource 1
3. Commit Last Resource 1
potential crash
4. Log XID
5. Commit XA resource 1
6. End transaction

The only way to safely support LRCO is to use the last resource as the global transaction (XID) store. If the last resource is the XID store, then the commit of the last resource and the XID become one atomic action - removing the window of opportunity for a crash between steps 3 and 4.

The last resource is an XA transaction here is always the database - due to the performance decrease is causes on the data layer and lack of DB vendor support for it.

To safely support the LRCO feature the JBossTS would need:

• Automatic selection of a TX store based on which database is enlisted as the Last Resource in the transaction. One of the TX stores should be able to be flagged as the default.
• A pluggable transaction store that allows for more than one TX Store, in the event there is more than one database configured in the container. This can be via a façade that federates the stores. This is needed so that the recovery process can access all of the XIDs.
• A more generic JDBC store implementation. The current implementation currently doesn't support many database vendors - particularly DB2 and Sybase.