Issue 056 - WS-AT: User Commit and User Rollback row of CV state table contradicts resolution of 010

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

This is identified as WS-TX issue 056.

Please ensure follow-ups have a subject line starting "Issue 056 -
WS-AT: User Commit and User Rollback row of CV state table contradicts
resolution of 010".

-----Original Message-----
From: Alastair Green [mailto:alastair.green@choreology.com] 
Sent: Wednesday, April 05, 2006 5:16 PM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] New Issue: WS-AT: User Commit and User Rollback row of
CV state table contradicts resolution of 010

Issue name -- WS-AT: User Commit and User Rollback row of CV state table

contradicts resolution of 010

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 should not return 
Aborted in None state


Issue Description:

Issue 010 proposed that replays of Completion protocol messages should 
be permitted, to allow initiators to discover state of transaction after

initial termination request had been made. This was rejected almost 
unanimously. However, state tables permit replay.


Issue Details:

WS-AT Coordinator View state table, row (Internal Events) User Commit 
reads as follows:

None:             Return Aborted --> None
Active:           Send Prepare --> Preparing
Preparing:        Ignore --> Preparing
Prepared:         N/A
Prepared Success: Ignore --> Prepared Success
Committing:       Return Committed --> Committing
Aborting:         Return Aborted --> Aborted

Similar things happen with row User Rollback.

Reception of User Commit engendered by Completion protocol Commit 
message may occur twice as a result of impatience, lost messages, 
transport bounce.

State table handles this happily, replaying known outcomes (e.g if event

arises when Aborting, Commit message will be responded to with 
Committed, even though message has already been sent on event Write
Done.

I like that, but the TC doesn't, by 16 to 1.

Note that this issue is very tightly related to "WS-AT: User Commit and 
User Rollback should not return Aborted in None state". If all become 
forgotten (every participant goes aborted or committed) then the state 
flips to None. Speed at which that happens cannot be dictated 
(forgetting is a non-critical path activity, that may be deferred to 
some form of garbage collection or deferred for ever in a given 
implementation). Replays are therefore always possible in principle.
 
Proposed Resolution:

EITHER:

Make text of completion protocol, definition of notification types etc 
conform with state table and recognize that duplicate Completion 
protocol Commits and Rollbacks cannot easily or sensibly be stopped (See

Register/RegisterResponse discussion).

OR:

Ban duplicate responses in the state tables by faulting duplicate
events.