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 your proposal is narrowly good, but is broadly unsatisfactory. It pushes the issue of duplication away from the state table (the state table can be insulated), but it leaves unanswered how duplication in the Completion protocol is to be handled. As that protocol is interoperable its behaviour in the face of duplication cannot be left to implementations, as I think you imply. If we do that then your proposed solution would evade a larger issue. See below for more on this.

A general review of the names of the events would be a good idea. They are far from intuitive (e.g. All Forgotten equals Read Only Decision). They also need to be defined, so that there is no doubt or ambiguity about what they mean. (Issue 048).

On your names: Commit Requested is correct -- the request may not be satisfied. Rollback Instructed might be more appropriate: it's an order unless it is played out of sequence (after a commit request).

You could also change the Completion protocol message names to RequestCommit and InstructRollback in line with this. This would avoid the overload between the Completion protocol and the 2PC protocol. They really don't mean the same thing. The Completion protocol participant is distinct and privileged: it is the only participant able to spontaneously "prepare" or "abort".

* * *

Completion protocol duplication

I fully understand the idea that we define these two internal events to be able to occur once only, which the state table change does. This protects the state table from duplicate messages. Screening out duplicates at this level (protection of the state machine) is an implementation issue. Incidentally, the state table is not protected against a Commit followed by a Rollback. Unless that sequence is prohibited somewhere, it is allowed. And as the completion protocol is optional (I assume) we can't rely on that to define the possible sequence

My question related to the response given by a Completion Coordinator if it is presented with a repeated outcome message (Commit, Rollback). The old line in the 2PC state table indicated that replays of response semantics could occur under certain circumstances.

Now we have no statement whatsoever. Your reorganization of the state table defers or displaces the problem raised by this issue to the externally visible interoperable protocol where duplication can occur. This is analogous to the discussion on duplication in WS-Coordination: we cannot assume this away.

Does a conformant implementation refuse to recognize duplicates (very odd, messages may be lost in both directions, and messages may be duplicated at the transport level), or does it replay responses? Furthermore, if a duplicate arrives after the coordinator has gone to None, we still need to know how to respond, which I think still requires Unknown Transaction (an interoperable message). The old state table showed replaying of responses in all of these circumstances, but played the wrong response (Aborted) in the None case.

This discussion is therefore a combination of this issue 055 and the closely related issue 056. Your proposed resolution of 055 is fine as far as the state table is concerned, but we can't sweep the issue of the Completion protocol under the carpet.

Alastair


Ram Jeyaraman wrote:

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.