ws-tx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: New issue: WS-AT: Invalid events should not cause defined transitions
- From: "Peter Furniss" <peter.furniss@erebor.co.uk>
- To: <ws-tx@lists.oasis-open.org>
- Date: Mon, 27 Mar 2006 22:33:02 +0100
Issue name -- WS-AT: Invalid events should not
cause defined transitions
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:
ws-at section 10, lines 503/505
coordinator table: Committed/Active,
Committed/Preparing
pariticipant table: Commit/Active,
Commit/Preparing
ws-at: seciton 6.1, line 371
Issue type:
Design/Editorial
Related issues:
Issue Description:
The receipt of a message when the receiver is in a
state such that the event cannot occur between correct implementations should
not cause a state transition and allow the transaction to complete
"successfully".
There is no need to distinguish "InvalidState" and
"InconsistentInternalState".
Issue Details
Background
InvalidState is defined in WS-Coordinator as being
an unrecoverable condition, and in all the cases where it is a defined
response in the WS-AT tables can only occur if one of the implementations is
broken/bugged (apart than the volatile
Prepared/None case, see separate issue). Providing a defined state
transition, as if the circumstance were expected and could be recovered from is
inappropriate. There can be no graceful completion of the protocol - it
has gone fundamentally wrong. This does not preclude an implementation from
attempting to tidy up and protecting its own
resources, but there should be no required state transition for the
implementation. The protocol exchange has gone off the map.
The use of InconsistentInternalState to distinguish
two cases where an invalid event occurs is unnecessary (and the definition in
line 371 does not align with the use in the table - it is probably the
coordinator that has been sending wrong messages).
The use of InvalidState is appropriate in all
cases.
Proposed resolution
The clearest solution would be to make invalid
cells in the state tables empty, for the cells currently shown as InvalidState
or InconsistentInternalState, and also for the N/A cells and explain this with
text:
"Where a cell is shown as
empty
- if the row is for an Inbound Event, an
WS-C Invalid State fault should be returned. The subsequent behaviour of the
implementation is undefined.
- if the row is for
an Internal Event, event cannot occur in this state. A TM should view these
occurences as serious internal consistency issues."
Having invalid cells empty makes it significantly
easier to read and check the state tables.
It becomes much clearer that they are essentially "sparse" and the path through
the table can be followed more easily.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]