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
Section
and PDF line number: section 10, coordinator view state table
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.