New Issue: WS-AT: User Commit and User Rollback row of CV state tablecontradicts resolution of 010

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

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