Re: counting prepares

[Mark Little <mcl@arjuna.com>]

> 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.

I haven't got my notes to hand, but at the last face-to-face didn't we agree
that a participant that says read/10/cancel (or whatever the syntax is for
saying "I'll cancel after 10 seconds though") wouldn't have to be contacted
by the coordinator again, because the coordinator can infer from this that
if, after 10 seconds it hasn't sent a confirm, it knows the participant has
cancelled, and can act accordingly? I also seem to remember that this was a
"the coordinator could send a re-PREPARE if it wanted to" but it didn't have
to. In any event, I don't think this contradicts what you are saying.

> 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.

Agreed. I thought we briefly discussed this possibility at the last
face-to-face but perhaps not. It's definitely an issue though.

[problem statement deleted]

> 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.

Basically your proposing the addition of sequence numbers to tie up the
request/response in an asynchronous message passing environment. Seems
reasonable to me.

> 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.

We don't need to demand that the issuer of PREPARE actually increase the
sequence number in all situations though. This can be on a per "round"
basis, so that if PREPARE N to the 3rd participant in the coordinator's list
doesn't get a response because the VOTE N got lost en route, it could
re-send PREPARE N. At the participant side if I wanted to implement a
retained results policy in the message gateway or somewhere else on the path
to the actual participant, I could get the original returned VOTE N response
out the results cache and resend it from there, without having to go to the
participant again. If the original PREPARE N was lost en route then there
wouldn't be a VOTE N in the cache, and I would have to go to the
participant, who wouldn't be able to differentiate this from having received
the first PREPARE N attempt.

However, I agree that if the coordinator needs to issue a truly "new"
PREPARE (as a result of receiving an INFERIOR_STATUS) then the sequence
number needs to be incremented.

This raises the question of whether we want to have this sequence number as
a general field in all BTP messages in order to tie up other message
request/response messages.

Mark.

----------------------------------------------
Dr. Mark Little (mark@arjuna.com)
Transactions Architect, HP Arjuna Labs
Phone +44 191 2064538
Fax   +44 191 2064203