[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
I have inserted some comments below. From: Peter Furniss
[mailto:peter.furniss@erebor.co.uk] 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. [Ram Jeyaraman] Right. 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. [Ram Jeyaraman] Yes. 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!) [Ram Jeyaraman] I am sure, we will agree that in the event of a
protocol violation, aborting the transaction is the logical thing to do. While
both InvalidState (IS) and InconsistentInternalState (IIS) faults indicate a protocol
violation, the difference between the two is in whether the violation had occurred
before or after an outcome decision was made. I believe this is consistent with
the current use of these faults in the specification. 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. [Ram Jeyaraman] Right. Clearly, there has been a protocol
violation. The two faults distinguish whether the violation occurred before or
after the outcome decision was made. If a protocol violation occurs after the outcome
decision has been made, the occurrence of the violation cannot change the
outcome; that is, the cells that throw IIS are not allowed to transition to a
different state. 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. [Ram Jeyaraman] The definition of IIS does not assume any
additional state transitions or internal events. Peter From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
The AT
specification’s specific use of InconsistentInternalState (IIS) fault is
to indicate protocol violations that occur after it is no longer possible to
change the outcome of the transaction; IIS is used in the PV table in the cells
{ Commit; Aborting } and { Rollback, Committing }. 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]