RE: 2001-06-01_OASIS_BTP_abstractmessages_DRAFT_1

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

> > I don't believe the rule "Heuristics can only occur if the
> participant has
> > received a
> > prepare" is valid for our protocol. Since we allow spontaneous ready
> votes,
> > and these can have timeouts (or just make autonomous decisions without
> > warning in extremis), it is possible to get heuristic decisions before
> > prepare has left the coordinator. We can guarantee that a heuristic mix
> > (=contradiction) will always get detected somewhere (i.e. at least one
> > entity that is any case required to hold persistent information will
> receive
> > a message showing the opposite decision), but can't guarantee that
> knowledge
> > will pass up tree if the coordinator cancels.
>
> I am assuming that spontaneous votes still fall into this rule,
> such that if
> a participant spontaneously votes *and* gets a reponse saying OK, then it
> can confirm or undo later. However, if it does not get a response to the
> vote *or* does not vote at all then it cannot generate heuristics and can
> only undo.

I don't think we can make such demands. The participant's timelimit is set
because it is driven by its own business requirements and is only prepared
to vote at all (making itself subject to anothers decision) if it can set
the rules.

We don't currently have an acknowledgement to the VOTE - just eventually the
decision will be received.

>            If we allow confirm/undo without vote/response then there are
> certain rollback optimisations we cannot make, e.g., consider the
> situation
> whereby a coordinator that attempts to prepare a participant finds that it
> is unreachable; normally the coordinator would then decide to rollback and
> tell all other reachable participants to do likewise, assuming that the
> failed one will (have) rollback too. However, now it cannot
> assume that the
> participant has/will rollback since it may have prepared and
> committed.

Yes, there is such a risk. If a one-shot reply carries
	enroll (no-response) + app response + vote/ready/confirm/10
but that gets lost (perhaps the initiator and coordinator crashed) and the
timer goes off, the participant will confirm on its own. It will still
attempt to run the recovery sequence (I'm doing the state table details
there at the moment) and detect there is a problem, even if the
initiator/coordinator have no surviving information.

This is only a risk where there are autonomous confirms (and in this case
with spontaneous ready).

I don't think there is any general protocol cure possible - by avoiding
various features of the protocol, you can ensure it can't happen in a
particular case (if location of participants is pre-known, spontaneous votes
are not used, autonomous confirm is not allowed etc.), but I think the above
is inevitable for the total combination. Or at least the cure will be worse
than the disease (essentially not allowing certain setups to use BTP because
they can't meet the demands for business reasons)

>                    So,
> the coordinator must make persistent all information about participants
> before it even enters the prepare phase so that it can contact them in the
> event of failures and find out what they did. I certainly wouldn't want to
> not know that an autonomous decision was made contrary to my preferred
> outcome.

with spontaneous VOTEs, you would have to make the information persistent
before sending the context out - but in general you don't know the
participants then anyway.  Hmm - perhaps that won't matter - if a
coordinator (manager) receives an incoming INFERIOR_STATUS/confirmed for an
atom that cancelled or is unknown, then it knows there was a contradiction.
It may not know what the transaction was about (or who the participant is),
but it knows something has gone wrong.

I forsee some white board diagram next week :-)

Peter