RE: [ws-tx] Issue 040 - WS-AT: Coordinator should not distinguish protoc

This issue is a duplicate of issue 039; editorial error on my part. I suggest closing this issue as a duplicate of issue 039.

From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
Sent: Tuesday, March 28, 2006 10:24 AM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] Issue 040 - WS-AT: Coordinator should not distinguish protocol of orphaned participants

This is identified as WS-TX issue 040.

Please ensure follow-ups have a subject line starting "Issue 040 - WS-AT: Coordinator should not distinguish protocol of orphaned participants".

From: Peter Furniss [mailto:peter.furniss@erebor.co.uk]
Sent: Monday, March 27, 2006 1:30 PM
To: Peter Furniss; ws-tx@lists.oasis-open.org
Subject: [ws-tx] New Issue - WS-AT: Coordinator should not distinguish protocol of orphaned participants

incomplete subject line - sorry.

Peter

Issue name -- WS-AT: Coordinator should not distinguish protocol of orphaned participants

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 Volatile 2PC

Artifact: spec

Draft:

AT spec cd 1

Link to the document referenced:

http://www.oasis-open.org/committees/download.php/17325/wstx-wsat-1.1-spec-cd-01.pdf

Section and PDF line number:

section 10, lines 503/505 tables rows Prepared, Relay, column None

Issue type:

Design

Related issues:

New issue: WS-AT: Invalid state inappropriate response to orphaned volatile participants

Issue Description:

The requirement that a coordinator with no current knowledge of a participant can determine which protocol it previously registered with from an incoming Prepared or Replay messages imposes unnecessary requirements on implementations. The desired functionality can be achieved with a common response to all such messages from "orphans", and letting the participant interpret that response.

Since a returned fault does not show in the state tables, there is currently no behaviour specified for the volatile participant that sent the Replay or Prepared (this will become a separate issue if the main one is rejected, but it gets subsumed if this is fixed)

Issue Details

Background:
The None state for WS-AT means that there is no record of the transaction - either because the transaction completed (rolledback or committed) or the coordinator crashed (and thus implicitly rolledback). Among correct implementations, Prepared and Replay messages received in the None state can only come from participants that were registered prior to the completion or crash, but did not receive a Commit or Rollback message.

For a durable participant, this cannot happen if the transaction committed - the coordinator cannot forget the transaction until it has received Committed from the durable participant. Thus if the Prepared or Replay are received from a durable participant in the None state, it can be inferred with certainty that the transaction rolledback (by intent or crash).

For volatile participants however, it is legitimate for the coordinator to delete its commit log record after receiving Committed from all durable participants, without waiting for any response from volatile participants. If there is a crash at this point (or just some lost messages), Prepared or Replay can be received from a volatile participant and find the coordinator in state "None".

The issue:
The specification currently requires that the coordinator distinguish between the two kinds of registration. This in turn requires that there is something about the Prepared or Replay message that allows the coordinator to determine the protocol of the forgotten registration (ipso facto, it has no specific, local information). Since there is nothing in the Prepared or Replay messages as such, this can only be something carried in or implied from the addressing for the coordinator. Although this can of course be done, and for some implementations may be entirely natural (e.g. if they have twinned-but-distinct multi-lateral coordinators for volatile and durable), for others it will be unnatural.

There seems no reason for imposing this peculiarity (other perhaps than the unstated aesthetic that the coordinator has the driving seat in this protocol). If the coordinator gave the same response to Prepared/Replay from either protocol, it would be up to the participant to determine how it should treat this response. Since the participant certainly knows how it registered, there would be no ambiguity.

(This issue has been distinguished from the question of using Invalid State in the volatile case - it would be even worse to use for InvalidState for the both protocols)

There is currently no defined behaviour for the volatile participant that sends Replay or Prepared (since fault behaviour is not defined).

Proposed resolution

Define new message UnknownTransactionOutcome.

Amend state table for Coordinator to send the new message when Prepared or Replay are received in state None.

Amend state table for Participant with row for inbound "UnknownTransactionOutcome"
this is invalid (shouldn't happen) in all states except PreparedSuccess

in PreparedSuccess
  if participant is Durable action is Initiate Rollback and Forget, transition to Aborting

  if participant is Volatile, action is Forget, transition to new state UnknownOutcome

UnknownOutcome state has transition to None on All Forgotten event. All other Inbound Events are ignored, without transition.

ws-tx message