[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 definedtransitions
+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-spec-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. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]