RE: [bt-spec] BTP Issue 52 : Forms of PREPARE

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

Sazi,

 

You sent:

 

 -----Original Message-----
From: Sazi Temel [mailto:sazi.temel@bea.com]
Sent: 27 January 2002 03:32
To: Peter Furniss
Cc: bt-spec@lists.oasis-open.org
Subject: RE: [bt-spec] BTP Issue 52 : Forms of PREPARE

At 01:10 AM 1/27/02 +0000, you wrote:

I am happy to concur with the strongly expressed feelings not to do this - PREPARE_INFERIORS can be for Cohesions only. I withdraw my suggestion about preparing bits of Coordinators.
 
 
In answer to Sazi's question, we do have the ability for a Initiator/Terminator to ask the status of an Atom, and even to see through it to the Inferiors - or indeed for anything to do so. Except that anything other than an Cohesion Composer can refuse to answer - either to anybody, or to people it doesn't like. A Cohesion Composer must answer to REQUEST_INFERIOR_STATUSES from the Terminator, but can refuse to others.
 
Having batted this about, I think we can now go to proposed solution (with the nice side effect that it doesn't change the document):
 
Proposed solution:
 
Resolved/clarified by agreed solution to [ISSUE 79]
 
PREPARE is sent by Superiors to Inferiors - since Sub-coordinators and Sub-composers are Inferiors, they receive PREPARE from their Superior
 
PREPARE_INFERIORS is sent by Terminators to Composers
 
There is no equivalent sent by Terminators to Coordinators - the only way a Coordinator is induced to send PREPARE to its Inferiors is by CONFIRM_TRANSACTION
 

So once the Coordinator receives CONFIRM_TRANSACTION it actually runs 2PO protocol, first PREPARE phase then CONFIRM phase, is this right? If so I think we should add an explanation in the spec with one or two lines, I do not think it is clearly stated in the spec.
 

I think it is stated in the text on CONFIRM_TRANSACTION, though that might benefit by changing "A confirm decision may be made only if PREPARED has been received from all Inferiors in the “confirm-set”." to "A confirm decision may be made only when (and if) PREPARED has been received from all Inferiors in the “confirm-set”. ". I am putting the essence of my message to Pyounguk on this issue (sent on Saturday night) into the model draft, which should explain the sequence more fully.

 

 Also please confirm my understanding of how Cohesion and Atom works now...

We have two types of termination protocols, one is cohesive one is atomic. Both protocol run in two phases, at first the participants are prepared and at the second they are confirmed or cancelled. 
 

they are not really that different. Just the Cohesion's terminator can do some extra things that don't make sense for an atom.

 

An atom is a cohesion whose confirm-set is defined at enrol time.

 

 
The difference between these two termination protocol is that
        Cohesive protocol
        1) allows terminator to drive the protocol, i.e terminator will first ask prepare and then make a decision on whether it will continue to confirm or not depending on the results of the first phase. 

it can ask for prepare on subsets of the inferiors too - and then cancel some or all of them if it doesn't like them and bring in new participants. there would be no point in trying to do that with an atom, because the new ones  (and any of the old ones that are left) would have to be cancelled too.

 
        2) allows to transition to prepared (or ready) state even if some of the participants are not prepared (unless non of the participants prepared it will transition to prepared state) if the terminator wants so. 

 

the composer can't go to confirm decision until and unless all of the Inferiors (participants) in the confirm-set have sent in PREPARED. what the other participants are up to at that point doesn't matter, because they get cancelled anyway.  Atom is the same, except there aren't any "other" participants.

 

Each individual Superior:Inferior (composer:participant) relationship transits to prepared-received as the PREPARED comes in, whether spontaneous, triggered by a PREPARE from PREPARE_INFERIORS, or triggered by PREPARE from CONFIRM_TRANSACTION. The Composer as a whole doesn't transition (to confirming) until and unless:

 it has received CONFIRM_TRANSACTION

 for all the Inferiors in the confirm-set PREPARED has been received

 it has persisted the confirm-decision

 

It is not up to the composer to decide which Inferiors are needed for the confirm decision - it is told by the application (in CONFIRM_TRANSACTION)

 

[aside: since support of the standard control relationship is not required, the spec has to allow for an equivalent proprietary or local means of sayingthe same thing]

 
        3) at the second phase, after prepare is completed and a confirm message is sent to participants, any contradicting outcome from the participants will be handled as heuristic.
  yes - contradicting meaning cancelled for the inferiors of the confirm-set, confirmed for the others. 

 
        Atomic protocol
        1) allows a terminator to ask the status of the participants before CONFIRM_TRANSACTION messages is sent. 

yes - but can do this to Cohesion too

 
        2) once the CONFIRM_TRANSACTION message is sent to the coordinator, terminator cannot interfere with execution of the termination protocol 

yes - also true of cohesion

 
        3) both phase of the termination protocol are executed sequentially, first prepare then confirm without ant pause in between. If any of the participants is not prepared at first phase, the protocol will abort. As in cohesion, any contradicting reply from participants at confirm phase will be handled as heruistic.
 yes

 
So the second phase is the same in both type of transactions. Note that I assumed that the participants may be 'participant/resource_coordinator' , participant/sub-coordinator, and participant/sub-composer in both protocol types, these are simply unknown to the coordinator/composer.
 

So understood. The spec uses "Inferior" to cover all of these, reserving Participant for "resource coordinator"

 
I think, as I have mentioned earlier, we need to include the protocol state transition diagrams for both coordinators (both cohesive and atomic) and the participants (whatever they might be) in the spec., I know Peter mentioned that there will be state diagrams in the spec - this is just a reminder :)

Thanks.

 

Peter

 

<snipped history>