Ram, comments interleaved.
Alastair
Ram Jeyaraman wrote:
Alastair,
In the case of an InvalidState fault, the transaction outcome remains
consistent. That is, if the transaction aborts, all the relevant parties
abort.
This is not the case. When Invalid State is returned to the other side
it means "you communicated a protocol error: I have no idea what you
and I are up to anymore. I cannot know how to proceed". This fault
message indicates that my interlocutor is (or I am) non-conformant,
bugged.
Example (among very many): Participant View state Preparing. Message
received Commit. At this point I (one participant of what may be many)
has received an outcome decision when I have not signalled Prepared to
the Coordinator. This should never happen (bug). Now, the current table
shows that the Participant should move to the Aborting state. We assume
that means that the P should initiate rollback etc (subject of another
issue). If it does, and rolls back, then there is no guarantee that the
bugged coordinator will send Commit to all other participants. The
Invalid State message conveys to the C the semantic that the P has
aborted. But there is no guarantee that a bugged implementation will
obey that: after all, it is bugged once, so why not twice?. The state
of the overall transaction is completely indeterminate. This is not
what is generally meant by a consistent outcome. As Peter pointed out
in the issue statement, it is wrong to carry out any state transition
at this point -- or at least, to any state other than We're Screwed.
Another example: Coordinator View in state Preparing. Receives
Committed. Sends message Invalid State. Goes into state Aborting. C has
no idea what the P is really up to (it should never have sent the
message Committed). If it assumes that the P has acted as if it had
received Commit (which could only occur if the C was bugged), then it
is now either going to commit the transaction as a whole (which
shouldn't happen if another P rolled back), or it is going to abort the
rest of the transaction (current, improperly expressed assumption), in
which case the transaction is definitionally inconsistent: one (or
more) Ps have committed, perhaps as a result of a C bug, all others
have aborted. Of course, it should never assume that the first P has
really committed, because if it (or the C itself) is bugged in one
respect (sending Committed early, invalidly, or promoting such an early
error, respectively) then either the P or the C may be bugged in any
other respect. The transaction is, once again, in an indeterminate
state.
In the case of InconsistentInternalState fault, the sending party has
unilaterally reneged on its commitment to consistency; that is, the
transaction outcome may be inconsistent across participants.
To communicate that a participant has reneged on its promise is to
convey that the participant has acted heuristically. The charter
prohibits this feature (heuristic reporting). I have never agreed with
that (not that it's that big a deal), but that's how the author
companies wanted it.
I understand that there is some confusion around this phrase
"participant cannot fulfill its obligations" used in the description of
InconsistentInternalState fault.
Perhaps rewording the description of InconsistentInternalState should
express the meaning as intended:
"This fault is sent by a participant to indicate a global consistency
failure. This is an unrecoverable condition."
-----Original Message-----
From: Alastair Green [mailto:alastair.green@choreology.com]
Sent: Friday, May 12, 2006 2:27 AM
To: Mark Little
Cc: Peter Furniss; Ram Jeyaraman; ws-tx@lists.oasis-open.org
Subject: Re: [ws-tx] Issue 041 - WS-AT: Invalid events should not cause
defined transitions
I think it's pretty obvious that these two messages are intended for the
same purpose (protocol error; non-conformant counterpart, all bets are
off).
I would like to see an explanation from the original author companies
for this duplication, and a proper argument that it is not redundancy.
Without that it seems very clear the AT message should go.
I also agree that no state transition should follow a protocol error,
i.e. the approach taken in Peter's sparse + text solution is correct.
Sparse versus verbose is a stylistic question.
Peter, I don't understand how a message like this could be used to
respond to internal events. To whom would it be delivered?
Alastair
Mark Little wrote:
+1
Peter Furniss wrote:
I agree that distinguishing circumstances of faults is generally a
good thing. Equally, one can also have too much of a good thing :-)
But the problem with InconsistentInternalState is that the definition
in the text doesn't correspond with the use in the state table.
Definition says its when the participant cannot fulfil its
obligations. That presumably would be apply when a participant has
gone prepared but now cannot obey the Commit or Rollback it receives
(which sounds suspiciously like a heuristic warning which would be
out of charter for this TC).
But the use in the state tables is that Participant sends it when it
receives contradictory messages from the coordinator - sending both
Rollback and Commit (in either order). That would seem to be no
different from any of the other InvalidState circumstances = "I am
receiving messages that should not happen in the state I am now in -
either you have sent a message you shouldn't have done or I've made a
state transition I shouldn't have done".
Receiving InvalidState should certainly cause an alert - but it's a
pretty serious one, because someone isn't conformant - the parties
aren't talking WS-AT any more.
InconsistentInternalState could be used in other circumstances,
aligned with its definition. It might even appear in the state table
- perhaps as action triggered from an internal event (which currently
appears as N/A, curiously)
Peter
------------------------------------------------------------------------
*From:* Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
*Sent:* 06 May 2006 01:42
*To:* ws-tx@lists.oasis-open.org
*Subject:* RE: [ws-tx] Issue 041 - WS-AT: Invalid events should not
cause defined transitions
As a consumer of a fault, I would rather receive a more specific
fault such as InconsistentInternalState, since it offer more specific
information and helps distinguish from other possible error states.
Specifically, upon receipt of an InconsistentInternalState fault, the
consumer may send an alert containing the specific cause, which is
otherwise not possible, if it receives a more generic fault.
Why should this fault be removed?
------------------------------------------------------------------------
*From:* Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
*Sent:* Tuesday, March 28, 2006 10:25 AM
*To:* ws-tx@lists.oasis-open.org
*Subject:* [ws-tx] Issue 041 - WS-AT: Invalid events should not cause
defined transitions
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]
*Sent:* Monday, March 27, 2006 1:33 PM
*To:* ws-tx@lists.oasis-open.org
*Subject:* [ws-tx] New issue: WS-AT: Invalid events should not cause
defined transitions
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
http://www.oasis-open.org/committees/download.php/17325/wstx-wsat-1.1-sp
ec-cd-01.pdf
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.
|