RE: [ws-tx] Issue 055 - WS-AT: User Commit and User Rollback should not return Aborted in None state

["Ram Jeyaraman" <Ram.Jeyaraman@microsoft.com>]

Alastair,

We should rename the "User Commit" and "User Rollback" internal events
to "Commit Requested" and "Rollback Requested", since these events are
fired exactly once, even though there may be erroneous or duplicate
Completion protocol messages.

Beyond that, it is not necessary to model the handling of erroneous or
duplicate messages; it is an implementation detail. The expectation is
that a Completion protocol message received during the Active state
would fire an internal event "Commit requested" or "Rollback requested"
exactly once.

-----Original Message-----
From: Alastair Green [mailto:alastair.green@choreology.com] 
Sent: Thursday, May 18, 2006 4:13 AM
To: Ram Jeyaraman
Cc: ws-tx@lists.oasis-open.org
Subject: Re: [ws-tx] Issue 055 - WS-AT: User Commit and User Rollback
should not 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.
>
>