RE: 2001-06-01_OASIS_BTP_abstractmessages_DRAFT_1

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

>
> BTW, thank goodness the document has line numbers :-)!

Sazi's sound suggestion.

I'll apply clarifications where we are agreed.

>
> What I meant was that once the participant has seen the entire termination
> protocol it can go away. If the coordinator had infact just failed before
> receiving CONFIRMED there's the possibility it may resend SUPERIOR_STATUS
> and find the participant has vanished.

Agreed. The state tables should make this clear. Part of the delay on their
visibility is that I've changed how I deal with persistence of state
information ( = logging) and failure.

> > page 14, line 13: state table sequences ensure that the
> "contradiction" is
> > certain to be known to the superior (which can then pass it on up), with
> one
> > exception: if the superior cancels, and does not persist any information
> > (which is its right under presume abort),
>
> It can only cancel without causing a heuristic if it hasn't received a
> prepare. That is within the presumed abort protocol. Autonomous
> cancel after
> prepare is into the domain of potential heuristics, which was the point of
> my comment in the document.
>
> > and there is a failure, the
> > subordinate will know there was a contradiction but there may be nothing
> at
> > home at the superior to tell. (This also occurs with both OTS
> and OSI TP -
> > hence heuristic hazard).
>
> See above. Heuristics can only occur if the participant has received a
> prepare. A participant (e.g., an OTS Resource) cannot arbitrarily commit
> unless it has first received prepare. It can arbitrarily roll back before
> prepare without causing heuristics, but once it has prepare a roll back is
> different.

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.

In writing out an example of this, I realised I hadn't sorted out which
messages are involved (I think the coordinator (or its manager) may receive
CONFIRMED for an unknown atom). State tables again.

Peter