[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 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:
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]