OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

bt-models message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: 2001-06-01_OASIS_BTP_abstractmessages_DRAFT_1

> 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
> 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
> a message showing the opposite decision), but can't guarantee that
> 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. 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. 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

If we always tie up VOTE and VOTED (sorry, haven't got the message document
next to me, so this may not be the right name) then we always have a well
behaved semantic for when heuristics are possible, and when rollback
optimisations like the one I outlined above can be used. Certainly in terms
of performance (cost of persistence and messaging) I do not want to lose
such optimisations.


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC