[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
Further interleaved: From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com] Sent: 18 July 2006 18:27 To: Peter Furniss; ws-tx@lists.oasis-open.org 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.
[Peter] No, I don't agree. The point is that there is no transaction protocol in use any more. We have truly no idea what the other side is up to - except that it isn't using WS-AT. It may be a good move to release local resources or resources at other participants, but that is local damage limitation - it may actually increase the chance of inconsistency.
[Ram Jeyaraman- paragraph broken by prf ] 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.
[Peter] the distinction is meaningless. The roof has fallen in. We don't know what is going on. see comment at end. 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]