RE: [ws-tx] Issue 081 -(and 079) WS-AT: state tables - Forget, Forgetting and Forgotten

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

Ian's solution does resolve the ReadOnly and User Rollback problems
raised in issue 079 - because the coordinator is in None, it can be
deemed that it is not aware of the User Rollback at all.  And, I think,
the reaction to various incoming messages would be essentially the same
(there may be a couple of cases where the change would now disallow the
sending of InconsistentInternalState).

However, the original proposal included a way of defining the different
between volatile and durable behaviour, without imposing on
implementations how this is achieved (i.e. by not allowing transition to
None from Committing for Durable we state that there is something
persistent, but don't have to say exactly what). This would seem to be a
Good Thing.

Peter

-----Original Message-----
From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com] 
Sent: 21 August 2006 21:02
To: Ian Robinson; Peter Furniss
Cc: ws-tx@lists.oasis-open.org
Subject: RE: [ws-tx] Issue 081 - WS-AT: state tables - Forget,
Forgetting and Forgotten

Yes, the All Forgotten row in the CV table does not seem all that
useful.

The proposed resolution to remove the All Forgotten row (along with the
concomitant changes) seems a fine way to resolve this issue.

-----Original Message-----
From: Ian Robinson [mailto:ian_robinson@uk.ibm.com]
Sent: Monday, August 21, 2006 8:59 AM
To: Ram Jeyaraman; peter.furniss@erebor.co.uk
Cc: ws-tx@lists.oasis-open.org
Subject: Re: [ws-tx] Issue 081 - WS-AT: state tables - Forget,
Forgetting and Forgotten

The state table represents the bilateral relationship between a single
participant and its coordinator. While there are a variety of ways that
a coordinator can get into "None" state, there can be no distinction
between these once a coordinator has forgotten its participant. This is
equally true for volatile and durable participants.

Its not clear that the "All Forgotten" row in the CV table is really all
that useful. Wherever the CV table shows a "Forget" action, then it
would be better to show the bilateral state change to "None".

I propose we resolve this issue as follows:
1. Delete the All Forgotten row from the CV state table.
2. All CV cells with an Action of "Forget" should be changed to show a
state transition to "None".

Regards,
Ian




             "Ram Jeyaraman"
             <Ram.Jeyaraman@mi
             crosoft.com>
To
                                       <ws-tx@lists.oasis-open.org>
             10/07/2006 21:42
cc

 
Subject
                                       [ws-tx] Issue 081 - WS-AT: state
                                       tables - Forget, Forgetting and
                                       Forgotten










This is identified as WS-TX issue 081.

Please ensure follow-ups have a subject line starting "Issue 081 -
WS-AT:
state tables - Forget, Forgetting and Forgotten".

From: Peter Furniss [mailto:peter.furniss@erebor.co.uk]
Sent: Monday, July 10, 2006 1:11 PM
To: Ram Jeyaraman
Subject: new issue - WS-AT: state tables - Forget, Forgetting and
Forgotten

Issue name -- WS-AT: Forget, Forgetting and Forgotten

PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL
THE ISSUE IS ASSIGNED A NUMBER.

The issues coordinator will notify the list when that has occurred.

Target document and draft:

Protocol:  WS-AT

Artifact:  spec

Draft:  AT spec cd 2

Link to the document referenced:

http://www.oasis-open.org/committees/download.php/18889/wstx-wsat-1.1-sp
ec-cd-02.doc

Section and PDF line number:  section 10, coordinator view state table


Issue type:  Editorial


Related issues:

Issue 036 : WS-AT - Coordinator state machine incomplete Issue 048 :
WS-AT - Internal events and actions undefined New issues:

Issue Description:


Issue Details

The existing coordinator view table has an "All Forgotten" internal
event that usually causes a transition to None.

Given the understanding that None means there is no longer any knowledge
of the participant, there are three rather different kinds of event that
cause transition to state None:

    a) the knowledge of this particular participant has gone as a result
of the Forget action, but knowledge of other participants may remain
    b) the knowledge of all participants has gone as a result of Forget
for all of them
    c) the knowledge of this participant (and perhaps some others) has
gone as a result of a crash (when there was no persistent information
for it)

The "All Forgotten" action is named for event b) (perhaps including
knowledge loss after crash), but given the purpose of the state table as
referring to an individual C:P relationship, it is actually its a) and
c) that are important. The volatile/durable distinction, and the
possibility that a readonly participant is forgotten early mean that the
completion of forgetting should relate to the single relationship, not
the whole node.

By separating out the Forgetting state as proposed in issue (new: WS-AT:
Forgetting state needed), event a) will now only occur from state
Forgetting. It thus becomes unnecessary to consider what is happening to
other state machines (to do so would be to impose on implementation,
anyway).

For event c), forgetting due to crash, requires different behaviour for
durable and volatile. The forgetting (= transition to None) can occur
from any state except where there is a commit log. By disallowing a
transition to None from the Committing state for a Durable partner it is
possible to capture the logging requirement without having to describe
at all how it is met.

All Forgotten as event name is misleading, as it implies volatile and
durable behave the same, which is incorrect.


Proposed resolution

Replace the All Forgotten internal event by two events:

internal event "Forget Completed", permitted only in state Forgetting,
where it causes a transition to None.

internal event "Forgotten by accident" which models transitions to None
from all states except Committing, where it is disallowed for Durable,
but transitions to None for Volatile.

Note that "Forgotten by accident" is an event imposed on an
implementation rather than done on purpose.