[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
Heuristic reporting, in general, has a larger scope, with respect to state retention, propagation, et cetera. The phrase "InternalInconsistentstate - the sending party has unilaterally reneged on its commitment to consistency" describes the purpose of such a fault, but this does not mean that the state tables correctly reflect that. Whether this is a useful distinction to make, in order to call out certain conditions, is a moot point. One may argue that it is useful in certain cases or situations, but, I agree that this does not apply universally. -----Original Message----- From: Peter Furniss [mailto:peter.furniss@erebor.co.uk] Sent: Saturday, May 13, 2006 2:55 AM To: Ram Jeyaraman; Alastair Green; Mark Little Cc: ws-tx@lists.oasis-open.org Subject: RE: [ws-tx] Issue 041 - WS-AT: Invalid events should not cause defined transitions Ram, Your phrase "the sending party has unilaterally reneged on its commitment to consistency" is the definition of heuristic decision. The implication of the unilateral reneging is indeed that the outcome is inconsistent, and why many similar protocols have heuristic reporting. (note that a protocol can never utterly forbid heuristic decisions by real systems, but it is a design choice whether the protocol includes heuristic reporting) Are you going to propose a change to the charter ? Peter -----Original Message----- From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com] Sent: 13 May 2006 03:19 To: Alastair Green; Mark Little Cc: Peter Furniss; ws-tx@lists.oasis-open.org Subject: RE: [ws-tx] Issue 041 - WS-AT: Invalid events should not cause defined transitions Alastair, In the case of an InvalidState fault, the transaction outcome remains consistent. That is, if the transaction aborts, all the relevant parties abort. 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. 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. >> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]