ws-tx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Ws-at state tables analysis
- From: "Peter Furniss" <peter.furniss@erebor.co.uk>
- To: <ws-tx@lists.oasis-open.org>
- Date: Mon, 28 Aug 2006 22:43:45 +0100
I've applied a state table checker to the WS-AT 2pc
tables as in the current working
draft (in fact, modified an existing checker
used for another protocol).
I took the tables as in the Word document,
transferred them to Excel then ran a macro that wrote them out as
tab-separated.
A perl program then reads the tables in and runs scenarios on
them. This was using
just the paired CV, PV tables. At each step, each side
offers the currently valid internal
events, and if a message is waiting to be
delivered, the delivery event. It also offers
to drop a message in
transit. The program can accept random choice of the available
actions
or be directed. (script choice and the comprehensive investigation of
all possible actions are
intended).
Checks on correctness are that the tables don't get
deadlocked (i.e they eventually reach None:None) and that the final states are
consistent.
The following observations are of
increasing significance. 1 and 2 are utterly
trivial are only arise because of the deliberately mechinical loading of the
tester; 3 - 6 are are peculiarities and inconsistencies that reduce the
quality of the tables. 7 is a bug.
1. CV, Preparing/Commit Decision: the new state is
stated as "Prepared Success", but the state name has no space in it.
2. PV,
Active/Rollback Decision : the new state is "Aborting " with a spurious trailing
space
3. Now we have regularised CV state
Aborting [to mean "I am waiting for
an Aborted reply to the
sent Rollback" (regularised as a result of 081 - previously it covered both this and a received
Aborted], it is appropriate to
define Comms Times Out in Aborting state, with action Resend Rollback/Aborting.
Without it, if a message is lost the state machines get stuck, with the
coordinator in Aborting, participant in None.
4. For determining final states, I considered that
the coordinator committed iff it the internal event "Write Done" occurred, and
that the participant committed iff it performed "Initiate Commit Decision";
rolled back if it performed "Initiate Rollback" and went read-only if it sent
ReadOnly.
However, there is an inconsistency with PV Rollback
Decision, which just has the action "Send Aborted", whereas all the other
rollback initiations, have "Initiate Rollback, Send Aborted, and Forget".
For consistency, shouldn't the PV Rollback Decision cells have the same actions
as e.g. Expires Times Out, receiving Rollback, Write Failed ? (c.f issue
038; the new issue 090 may affect the Forget action and the resulting state,
but Initiate Rollback would seem to be needed anyway)
5. PV table has All Forgotten/None with transition
None. This doesn't seem consistent with the usual interpretation of state
None, that the bilateral relationship is extinct, and internal events do not
occur for it. This may be sorted out by changes from issue 090.
6. In the PV table, event "Commit Decision" occurs
twice, with obviously different meanings. The form valid in state Preparing
ought really be called something else (Prepare Decision), and the action name
changed to - it isn't Record Commit, but Record Prepared. [ i think I remember
some earlier discussion on this; apologies if I've forgotten a deliberate
decision; no apologies for raising the point]
7. CV table, allows Commit Decision in Preparing.
This makes it possible for the CV to proceed to a commitment, before the
participant has replied, leading to an inconsistent result. It clearly
should not be possible for CV to get to PreparedSuccess *with respect to this
participant* until it has received Prepared *from this participant*. I'm afraid
we need to re-instate the CV "Prepared" state.
I've not mentioned inconsistencies that are
addressed in issue 090.
Peter
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]