New issue: WS-AT: Coordinator state machine incomplete

["Peter Furniss" <peter.furniss@erebor.co.uk>]

Issue name -- WS-AT: Coordinator state machine incomplete

 

PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER.

 

The issues coordinators will notify the list when that has occurred.

 

Target document and draft:

 

Protocol:  WS-AT

 

Artifact:  spec

 

Draft:

 

AT spec cd 1

 

Link to the document referenced:

 

http://www.oasis-open.org/committees/download.php/17325/wstx-wsat-1.1-spec-cd-01.pdf

 

Section and PDF line number:

 

section 10, lines 493 - 510

 

Issue type:

 

Design / Editorial

 

Related issues:

 

New issue: WS-C, WS-AT, WS-BA: Term "Coordinator" overloaded
New issue: WS-AT: Register/Preparing in coordinator state table problematic

 

Issue Description:

 

The WS-AT coordinator state tables do not provide explanation of what the states or internal events are, and do not provide specification of the interactions between the completion, volatile and durable protocols.

 

 

 

Issue Details:

 

The WS-AT state tables are described as showing " the view of a coordinator or participant with
respect to a single partner. A coordinator with multiple participants can be understood as a collection of
independent coordinator state machines". In fact they appear to use the states and internal events of the multi-lateral coordinator but inbound events for a single partner. In the absence of any explanation, especially of the internal events, this is confusing (and there seem to be some inconsistencies).

 

There is also little or no specification in the state tables of the interactions between the completion, volatile and durable protocols (which essentially determine that the transaction is atomic).

 

Evidence of multilateralism:
 A bilateral state engine will move from None to Active on receiving Register. "Active" thus has to be interpreted as the state of the multilateral coordinator.
 Receipt of ReadOnly would cause a bilateral state engine to go from Active to None - the tables show it as having no effect on the state.
 
Lack of protocol interaction
 the tables provide no specification of the volatile-first behaviour - except perhaps in the Register/Preparing cell, which is cannot be harmonised with the rest of the table (see separate issue)
 
 if "User Commit" is to be interpreted as Commit on the Completion protocol (or its non-standardised equivalent), then a Prepare shouldn't be sent to a Durable Participant until all the Volatiles have replied.
 
 The Commit Decision event is presumably meant to occur when all participants have replied Prepared or ReadOnly, but according to the state table it could occur any time after Prepare has been sent.

 

Proposed Resolution:

 

Create separate tables for the multilateral and bilateral relationships, and define what all the states and events mean.