Re: [ws-tx] Issue 081 - WS-AT: state tables - Forget, Forgetting andForgotten

[Ian Robinson <ian_robinson@uk.ibm.com>]

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-spec-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.