[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 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. 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 outcome. 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. Mark. ---------------------------------------------- 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