RE: [ws-tx] Issue 090 - WS-AT: Volatile amnesia

["Peter Furniss" <peter.furniss@erebor.co.uk>]

I believe the VolatileForgotten cells for CV Committing and PV
PreparedSuccess should be

	Volatile : None
	Durable  : N/A

And a transition to None for VolatileForgotten/Aborting on both tables.

That allows a clear way of specifying the difference between the two
protocols, without any implications on how it is implemented.


Peter 

-----Original Message-----
From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com] 
Sent: 28 August 2006 02:13
To: Alastair Green; ws-tx@lists.oasis-open.org
Subject: [ws-tx] Issue 090 - WS-AT: Volatile amnesia

This is identified as WS-TX issue 090.

Please ensure follow-ups have a subject line starting "Issue 090 -
WS-AT: Volatile amnesia".

-----Original Message-----
From: Alastair Green [mailto:alastair.green@choreology.com]
Sent: Saturday, August 26, 2006 7:10 AM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] NEW ISSUE -- WS-AT: Volatile amnesia

Protocol:  WS-AT

Artifact:  spec

Draft:  AT specification WS 10

Link to the document referenced:

http://docs.oasis-open.org/ws-tx/wstx-wsat-1.1-spec-wd-10.pdf


Section and PDF line number:  Section 10,  CV and P state tables


Issue type: design


Related issues: 081


Issue description:


Following resolution to 081, we are left with two related sub-issues, as
discussed in 24/8 TC. This issue aims to scoop these up in one go.


1a. CV now transits directly to None whenever machine Forgets. This
enabled removal of All Forgotten row. P table has the same feature
(transition to None results from All Forgotten, which is implicitly
generated by Forget action). I see no reason not to align P table with
this approach.

1b. P table is also inconsistent, internally, and with regard to CV
table, in that actions which should lead to None do not say "Forget"
except in the case of Commit Decision/Prepared Sucess.

2. Resolution of 081 failed to address the fact that volatile
relationships can transit to none through deliberate or accidental
amnesia (volatile participants are defined as ones which are not
guaranteed to receive the outcome, and either end could therefore decide
to wipe its records of the transaction, or could have them wiped by a
crash without subseqent recovery). This is not addressed in the state
tables, which only allow transition to None through
transmission/reception of the past participle messages.


Proposed resolution:

1. Relabel P table row All Forgotten as "Read Only Decision" and change
the Committing/Aborting columns in that row to "N/A".

2 Option A. All P table cells that cause a Send X, which then leads
(directly/indirectly) to None, should contain a final action Forget, and
should uniformly show a state transition "None". E.g. "Send Read Only
and Forget"; "Send Aborted and Forget".

2 Option B. Remove action Forget from CV and P tables, and ensure that
all final actions which lead to None show that explicitly without
indirection through All Forgotten (as per 081 and resolution of this
issue, 1. above). This would be more consistent with resolution of this
issue, 3. below.

3. Add a new row to both CV and P tables, following Max's suggestion,
called "Volatile Forgotten". All cells are "N/A" apart from
Committing/Aborting. These should read  "None".

[NOTE: Volatile Forgotten (which will not be formally defined, in line
with a prior TC decision) is taken for the purposes of this resolution
to mean: "The coordinator view ! participant implementation is free to
forget a bilateral relationship where the participant is volatile,
either through positive action or post-crash amnesia, once the
relationship is successfully prepared, as there is no obligation to
deliver the outcome to volatile participants. The action or fact of
forgetting in this way is represented by the internal event Volatile
Forgotten." For the avoidance of doubt, this definition is not part of
the proposed resolution.]