[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-tx] Issue 041 - WS-AT: Invalid events should not cause defined transitions
The current
definition of IIS does not correctly reflect its intended use. Hence, rewording
its definition consistent with the aforementioned use: "This
fault is sent by a participant or coordinator to indicate that a protocol
violation has been detected after it is no longer possible to change the
outcome of the transaction. This is indicative of a global consistency failure
and is an unrecoverable condition." Further, the
cells in the CV table should throw IIS fault (instead of InvalidState) from the
following cells: Format: {Row;
Column1, Column2} 1. {ReadOnly;
PreparedSuccess, Committing} 3. {Committed;
PreparedSuccess, Aborting} From: Ram Jeyaraman
[mailto:Ram.Jeyaraman@microsoft.com] This is identified as WS-TX issue 041. Please
ensure follow-ups have a subject line starting "Issue 041 - WS-AT: Invalid
events should not cause defined transitions". From: Peter Furniss
[mailto:peter.furniss@erebor.co.uk] 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: http://www.oasis-open.org/committees/download.php/17311/wstx-wscoor-1.1-spec-cd-01.pdf Section
and PDF line number: ws-at
section 10, lines 503/505 Issue
type: Design/Editorial
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 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]