[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
Ram and others,
The InconsistentInternalState issue is a secondary
aspect of 041, whose main point is not about the fault sent but about what
state the table is in after the event occurs.
First, I better make sure we agree that a protocol
violation means that one implementation has stepped off the path and either sent
a message it is not allowed to in the current state, or has performed a state
transition it is not allowed to. Assuming that is what is meant by protocol
violation, it means the entire contract has broken down - the rules have been
broken and the implementations are no longer following our specification. There
is no shared semantic any more.
Accordingly, there is no way the specification can
ever expect to achieve global consistency, whereever the parties are in the
lifecycle - at least one of them isn't obeying the rules.
In consequence, the specification should not *require* a
transition to another normal state for ANY protocol violation. Implementations
should be left completely free to devise their own strategy for minimise the
local damage and reporting to management. They might choose to trigger local
abort (or do so only for certain states) but there isn't any general real
guarantee that this will increase the chance of a consistent outcome across the
transaction. (e.g. if Committed is received in Active state, it would seem
possible that the participant has already committed - so aborting would make
matters worse!)
However, it's possible that we see this differently
because our different understandings of the state table. If the
understanding is that implementations are free to send protocol messages and
make (abstract) state transitions as they feel fit, then my definition of
protocol violation is unsound. An implementation sending surprising messages or
changing state hasn't violated the protocol, because there is no rule to say it
can't do that - it's just exercising it's right and the "protocol violation"
would be just that the receiver didn't expect the message. But then it is even
more certain that the parties don't know what the other is up to when the
surprise message arrives.
Returning to the secondary point of the definition of IIS,
on either understanding, the distinction "no longer possible to change the
outcome" (from an earlier condition, "is possible to change the outcome") would
seem to be spurious. Once the protocol has been violated or the receiver is
surprised, there is no way of knowing what the other side is up to or what they
perceive the outcome to be.
I'm not sure whether your
definition of IIS assumes that there are some additional semi-permitted state
transitions that correspond to anonymous, but actually well-defined, internal
events. For example, do you believe that the arrival of Commit at a Participant
in Aborting state (for example) will occur in semi-normal (i.e. unusual but
bug-free) circumstances when the Participant in PreparedSuccess has made an
internal decision to locally initiate rollback - and by doing so transitions
itself to Aborting. Such an action isn't defined in the state table, but, if the
"anything-is-permitted" understanding is followed might be an
implementation-defined action in the case of a heuristic decision. IIS would
then be a (non-reliable) heuristic report. But to explain the why of that, there
ought to be an internal event that reflects the transition to Aborting.
Otherwise there is no reason to believe that an implementation that had locally
initiated rollback would be in Aborting state - it would be equally rational to
say that such an implementation was still in PreparedSuccess, but had released
resources.
Peter From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com] Sent: 12 July 2006 07:35 To: ws-tx@lists.oasis-open.org 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]