elaborate on ordering semantics for Synchronization calls in a distributed transaction

[glassfishrobot]

This is being opened to track the topic and whether it warrants elaborating in the spec.

Email exchange between Paul Parkinson and Ian Robinson...

Paul:

"
Something I've always thought of, especially since the TransactionSynchronizationRegistry was introduced, is whether we should mention anything in the spec about the ordering semantics for Synchronization calls in a transaction that is distributed across multiple transaction managers/processes.

As far as I can tell all transaction managers in existence issue Synchronization.beforeCompletion calls locally just before the prepare calls on each node of a transaction and there is no "0/beforeCompletion phase" whereby all Synchronization.beforeCompletion calls are made down the entire transaction/process tree before starting the prepare calls down the entire transaction/process tree.

This is no surprise as the performance cost would be significant, however, the spec states "The Synchronization.beforeCompletion method is called prior to the start of the two-phase transaction commit process" and the javadoc for registerInterposedSynchronization) states "beforeCompletion will be called after all SessionSynchronization beforeCompletion callbacks and callbacks registered directly with the Transaction, but before the 2-phase commit process starts"

So one might argue that it is a violation to call prepare from/on one node of a transaction when Synchronization.beforeCompletion calls have not been made on another node involved in the same transaction.

Any thoughts?
"

Ian:
"
This is right - as you say, the ordering of Synchronizations and XAResources are always localized within the scope of a JVM which may be one branch of a distributed transaction. In all the implementations I know, only the first and second phase are strictly distributed across the whole tree with the volatile (Synchronization) work always ordered wrt 2PC only within the local JVM. OTS itself supports distributing before/afterCompletion but I don't know anyone who pays the performance price to do that.
Its a similar consideration for JCA connection sharing - different components that access the same resource provider in the same global transaction should share a Connection but that is only true if the application components are deployed to the same AppServer (JVM).
The Synchronization ordering is safe so long as you DON'T share connections or join (tightly couple) transaction branches between servers (JVMs) in a global transaction. If you did that then you would need to worry about work-after-prepare in the downstream nodes.

So I don't think we have anything to worry about here unless you think this needs clarification. I certainly wouldn't want to require any change in behaviour.
"

[glassfishrobot]

@glassfishrobot Commented
Reported by paul_parkinson

[glassfishrobot]

@glassfishrobot Commented
This issue was imported from java.net JIRA JTA_SPEC-11

[glassfishrobot]

• Issue Imported From: elaborate on ordering semantics for Synchronization calls in a distributed transaction  javaee/jta-spec#11
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @glassfishrobot