Issue 063 - WS-AT: Volatile 2PC logging behaviours unclear

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

This is identified as WS-TX issue 063.

Please ensure follow-ups have a subject line starting "Issue 063 -
WS-AT: Volatile 2PC logging behaviours unclear".

-----Original Message-----
From: Alastair Green [mailto:alastair.green@choreology.com] 
Sent: Wednesday, May 31, 2006 3:47 AM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] NEW ISSUE -- WS-AT: Volatile 2PC logging behaviours
unclear

Issue name -- WS-AT: Volatile 2PC logging behaviours unclear

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 3.4, "Two-Phase Commit Protocol", ll. 221-223
Coordinator View State Table, after l. 503
Participant View State Table, thereafter


Issue type:

Design/editorial


Related issues:

[WS-AT: Is logging mandatory?]


Issue Description:

Coordinator and Participant logging behaviour for Volatile participants 
is not defined.
 

Issue Details:

The following sentence comes from the original statement of Issue 039 
(authored by Peter Furniss):
 
'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".'

This is, I believe, an understanding derived from discussion with one of

the input authors at the Raleigh interop event in January 2005.

This is one implementation of the spec statement (l. 180): "A volatile 
recipient is not guaranteed to receive a notification of the 
transaction's outcome."

That statement can also be fulfilled by a volatile participant not 
logging its prepared state. This will prevent it always receiving a 
known outcome (i.e. there will be no crash recovery of the Participant).

The interoperable behaviour in these two cases is different.

Behaviour in the case where the PV does not log, and the coordinator 
deletes its log after receiving all durable Committeds, is different
again.

The state tables do not capture the expected behaviour of either the 
coordinator, or the Participant, with respect to logging.


Proposed Resolution:

Discuss and clarify the design intent, and ensure that it is captured in

the spec, preferably in the state tables.