ws-tx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: New issue: WS-AT: Coordinator state machine incomplete
- From: "Peter Furniss" <peter.furniss@erebor.co.uk>
- To: <ws-tx@lists.oasis-open.org>
- Date: Mon, 27 Mar 2006 22:06:27 +0100
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:
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]