Comments interleaved.
Ian Robinson wrote:
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.
Commit Decision in the second case means: "commit enacted, able to
delete log". The name of the event is a bad name, and the lack of
formal definitions doesn't help.
There are two completely separate internal events here:
1) deciding to go prepared --> write the prepared log, and
2) successfully reacting to commit instruction/completing commit
processing on controlled resources --> able to send Committed +
delete log
I think Peter is right that dividing into two rows (e.g. Prepared
Decision, Commit Work Completed) would make this clearer.
It's not "wrong" -- it's just counter-intuitive and under-specified.
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.
This has come up before, and the status quo is again under-specified.
Record Vote creates a state transition (to a state we could call
"Locally prepared"), and the event Commit Decision (which is understood
by the oldest inhabitants of the village to mean: "the unmentionable,
invisible global coordinator has decided to commit the whole
transaction") can only legitimately occur once this branch is in the
state Locally Prepared.
The state table is half correct, if the secret constraint is taken as
read. It would have been better to drag it out into the light of day,
but we've already decided to leave it unspoken.
Introducing a new state like Locally Prepared would make things
clearer. It would show that replays of Prepared will not cause repeated
Record Vote actions, but will be ignored once in Locally Prepared.
The old "Prepared" state didn't do anything useful at all -- its loss
simply removed an historical relic.
Alastair
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
|