[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 055 - WS-AT: User Commit and User Rollback shouldnot return Aborted in None state
Ram, I think that is correct, and is a good solution to this issue. You (correctly) say that repeated transmissions of Completion protocol messages cannot be avoided or prevented. How should a Coordinator respond to such retransmissions when receiving duplicates from a Completion protocol Participant? The proposed change, while cleaning up in a good way, now makes it less clear what should happen in this respect, as there is no interaction or overlap between the 2PC state table, and the CP state diagram -- which does not show how duplicates would be handled. Alastair Ram Jeyaraman wrote: > The CV 2PC state table currently treats the User Commit and User > Rollback as inbound events, instead of as internal events. An internal > event triggered as a result of a Completion protocol would fire exactly > once during the Active state. If such an *internal* event occurs during > other states, it indicates an internal failure; it should not happen. > > Note this does not mean that the participant of a Completion protocol > cannot resend messages or send messages in incorrect sequences; only > that such erroneous or duplicate messages would not trigger an internal > event (User Commit or User Rollback) that kick-starts the 2PC protocol. > > Please find attached a modified table that illustrates the > aforementioned behavior; that is, the internal events (User Commit and > User Rollback) has valid state transitions only for the Active state. > > -----Original Message----- > From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com] > Sent: Thursday, April 06, 2006 10:54 AM > To: ws-tx@lists.oasis-open.org > Subject: [ws-tx] Issue 055 - WS-AT: User Commit and User Rollback should > not return Aborted in None state > > This is identified as WS-TX issue 055. > > Please ensure follow-ups have a subject line starting "Issue 055 - > WS-AT: User Commit and User Rollback should not return Aborted in None > state". > > -----Original Message----- > From: Alastair Green [mailto:alastair.green@choreology.com] > Sent: Wednesday, April 05, 2006 5:14 PM > To: ws-tx@lists.oasis-open.org > Subject: [ws-tx] New Issue: WS-AT: User Commit and User Rollback should > not return Aborted in None state > > Issue name -- WS-AT: User Commit and User Rollback should not return > Aborted in None state > > 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: > > WS-AT CD 0.1 uploaded > > Link to the document referenced: > > http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17325/ws > tx-wsat-1.1-spec-cd-01.pdf > > Section and PDF line number: > > Section 10, "State Tables", Coordinator View table, between ll. 503 and > 504 > > > Issue type: > > Design > > > Related issues: > > New Issue: WS-AT: User Commit and User Rollback row of CV state table > contradicts resolution of 010 > > > Issue Description: > > If transaction in state None, and event User Commit or User Rollback > arises, then action is to Return Aborted (aka tell application that the > transaction was aborted). In fact transaction may just have been > forgotten, and may either have been aborted or committed. Return value > possibly contradicts reality, therefore. > > > Issue Details: > > All Forgotten event arises when all participants have done action > Forget. If this happens when transaction as a whole is in Aborting or > Committting state then the state flips to None. > > User Commit or User Rollback event may then arise. (Replay of Completion > > protocol Commit, API replay). Response of coordinator state machine is > to process action "Return Aborted". See WS-AT Coordinator View state > table, rows (Internal Events) User Commit and User Rollback, which read > as follows: > > User Commit/None: Return Aborted --> None > User Rollback/None: Return Aborted --> None > > Clearly this information may be false. It is possible that we got to > None via Committing, or via Aborting. The result was either Committed or > > Aborted. Naturally, if we have gone "All Forgotten" we have literally > ... forgotten which it was. > > > Proposed Resolution: > > a) Amend state table cells referred to in problem description to read: > > User Commit/None: Return Unknown --> None > User Rollback/None: Return Unknown --> None > > b) Define new fault for use by Completion protocol, called > UnknownOutcome, which can be returned if this happens. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]