Re: Suggestion for a 2PC optimisation


 

I worked on the original XA prototype and wrote the draft XA specification that was submitted to X/Open.

The goal of xa_start/xa_end is to associate a thread with a transaction/resource.  There can be many such associations for a global transaction/resource on different threads within a process, on different processes, and different machines.  It's not just a simple start/end, we are done, and we have the answer based on a single return value.

We extended that goal only for the rollback case, where a rollback from any association on the transaction indcates that the entire transaction will be rolled back.   We don't need to worry about the return values from other associations with the transaction.  This optimization allows for the TM to short-cut even starting subsequent associations for the same transaction, propagating communications associated with the transaction, etc.

Extending the goal to provide read-only information is not so straight forward.  The fact that one association returns read-only does not imply that we can take any action other than keeping track of that piece of information because there could be many other such associations for the transaction/resource that are not read-only.  So the read-only information would need to be tracked, ignored if any related association returns OK, combined across all associations everywhere, and can only be acted on in the first phase of commit when we know there will be no further associations allowed. If all associations for the transaction/reesource are read-only, then 1PC can be used.  I don't believe that we considered returning read-only from xa_end.

Adding this feature now would be complicated because it impacts both the RM and the TM.  Most if not all changes to the JTA specification impact only the TM.   Changing the RM can cause a behavior in the unupdated TM that is not expected.  I can see the code that was written 30 years ago with a switch on the return value from xa_end and it doesn't handle XA_RDONLY (unknown return values are treated as an error that causes the transaction to fail).

Join jta-spec@javaee.groups.io to automatically receive all group messages.