counting prepares

[Peter Furniss <peter.furniss@choreology.com>]

In revising the state table, I've come across the following complications:

We currently allow a superior that has received VOTE/ready from a
subordinate to issue another PREPARE. It must then wait for the new VOTE.
This VOTE can be either ready or cancel.  This is largely to allow for
re-voting where there are time-limited votes, especially in the case that
the time limit is approached or exceeded - the new vote might extend the
limit, or clarify (i don't want to use the word "confirm") that the timer
has gone off and the atom should be cancelled entirely. Note that this
applies whether the first VOTE is spontaneous or is a response to an earlier
PREPARE.


Effectively, the issuing of a PREPARE after receiving the VOTE means the
superior has lifted the obligation on the inferior to hold the ready state -
accordingly the superior cannot decide to confirm until it gets the new vote
in. Otherwise you could have CONFIRM crossing with VOTE/cancel, which would
require different logging/persistence rules.

However, this has some tricky interactions with recovery. If the inferior
recovers with a ready log, it will issue INFERIOR_STATUS/ready to find out
what is going on/prompt the superior.  If this arrives when the superior has
sent out PREPARE, the superior can't tell whether the status ready refers to
that from the original vote (which might be just about to get changed), or
is the status after replying to the outstanding PREPARE (for which the VOTE
presumably got lost).  The superior thus can't treat the
INFERIOR_STATUS/ready as if it were the reply.

A solution would be for the superior to resend the PREPARE, to induce an
explicit VOTE that hopefully doesn't get lost. However, then there would be
multiple outstanding PREPAREs. But this can be coped with by putting a
counter on the PREPARE, and having that counter echoed on the VOTE. VOTEs
received with lower numbers than the last sent PREPARE are just ignored.

This counter can replace the spontaneous/response flag that is currently on
VOTE - the counter starts at 1, and a spontaneous VOTE has a counter of
zero.

We can't demand that the most recent counter is present on the
INFERIOR_STATUS/ready, because it is not reasonable to demand that the log
record be re-written every time there is a re-vote. But the
INFERIOR_STATUS/ready could carry the counter - if this is that of the last
PREPARE, there is no need to send another one.

Does this seem reasonable?  It's going to mess up my state table processor,
but that's my problem :-) (except that this will delay the revised table :-(




Peter

------------------------------------------
Peter Furniss
Technical Director, Choreology Ltd
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N 2JX