Re: [ws-tx] Issue 055 - WS-AT: User Commit and User Rollback shouldnot return Aborted in None state

[Alastair Green <alastair.green@choreology.com>]

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.
>
>