RE: [ws-tx] Ws-at state tables analysis

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

Ian,

Your message arrived just as I sent the issue proposal for item 7. 


On 6, what the action and the events are called doesn't matter a great
deal. (Yes, Record Prepared would be the same thing)

But having two importantly different internal events with exactly the
same name seems to be merely confusing. Are table rows expensive ? It's
exactly the sort of thing we would be likely to get PR comment on.


On 7, one could deem that "Commit Decision" requires a previous "Record
Vote". In other words that there is a state change on receiving
Prepared, which makes the Commit Decision legitimate, whereas
previously, Commit Decision was not allowed. Which is exactly the sort
of thing that the state table is designed to represent.  And this isn't
a question of the behaviour on the other parallel state machines, but
directly of this one. One might as well collapse the entire table.

Peter

-----Original Message-----
From: Ian Robinson [mailto:ian_robinson@uk.ibm.com] 
Sent: 29 August 2006 15:29
To: Peter Furniss
Cc: ws-tx@lists.oasis-open.org
Subject: Re: [ws-tx] Ws-at state tables analysis

Peter, I have comments on your last two observations:
>> 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]

"Record Commit" simply means record the decision of the participant to
vote to commit. "Record Prepared" would have exactly the same meaning.
Splitting the "Commit Decision" row into 2 separate rows in the table
for the distinct actions in Preparing and Committing state seems
unnecessary.

>> 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 disagree with this. The "Commit Decision" requires the "Record Vote"
action to have occurred, which requires a wsat:Prepared message in the
Preparing state.


Regards,
Ian


 

             "Peter Furniss"

             <peter.furniss@er

             ebor.co.uk>
To 
                                       <ws-tx@lists.oasis-open.org>

             28/08/2006 22:43
cc 
 

 
Subject 
                                       [ws-tx] Ws-at state tables
analysis 
 

 

 

 

 

 





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