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

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

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


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


Hi Peter,
    Please, see my comment inline below.
 
Pyounguk
-----Original Message-----
From: Peter Furniss [mailto:peter.furniss@choreology.com]
Sent: Monday, January 28, 2002 1:25 AM
To: Sazi Temel
Cc: bt-spec@lists.oasis-open.org
Subject: RE: [bt-spec] BTP Issue 52 : Forms of PREPARE

Sazi,
 
Useful discussion. I'll snip to your comments.
 
        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.
 

Agreed. If we put this into a state diagram, what I am saying is that the cohesion will transition to ready/prepared state if there is at least one (out of many) participant that is prepared,  but atom will go to cancel state if any of the participants failed/canceled.  
 
that's right for an atom (except "failed" might need some detailing)
 
but the cohesion will only immediately go ready/prepared if the prepared participants are all of those in the confirm set, and will go to cancelling if any confirm-set participant report cancelled.
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
 

I was trying to underline that a CONFIRM_TRANSACTION message sent to atom coordinator starts the execution of 2PO protocol, first prepare then confirm/abort; but the same message sent to cohesive coordinator starts the second phase of the 2PO protocol, i.e confirm since a cohesive coordinator that receives this message must already be prepared (the confirm set). I know all these info is in the spec, but I think it would be clearer if we put the sequence of the messages sent/received from/to roles in this type of context in stead of just stating what role can sent/receive what messages.   

Just that I thought I understood what you explained.... I have to make sure... Do you, by any chance, mean a terminator can sent CONFIRM_TRANSACTION message to a cohesive coordinator before sending a PREPARE_INFERIORS message? The reason for I am asking this is that you have mentioned above that
        An atom is a cohesion whose confirm-set is defined at enrol time.

which may also mean a specific (whose confirm-set includes all participants) cohesion is an atom... So do you mean  if a confirm_set of a cohesion covers all the inferiors (like in an atom), on receiving a CONFIRM_TRANSACTION message from the terminator, such cohesive coordinator will act like atom coordinator (no need of receive PREPARE_INFERIORS message first) and run both phases of 2PO protocol?  - A kind of optimization! I am not saying I like the idea neither saying you mean it..
 
Yes, and slightly more than that. For a cohesion, CONFIRM_TRANSACTION can be issued without any prior PREPARE_INFERIORS, and the confirm-set identified can include all or just some of the Inferiors. Assuming no spontaneous PREPAREDs, the cohesion composer will then run the prepare phase on those Inferiors. So, yes,  if the confirm-set is all of the Inferiors, the cohesion behaves like an atom. (as a cohesion, it didn't promise to behave like that, but in this instance, it did)
 
[Cho, Pyounguk] At least in the 0.9.0.x versions of the spec, I was under the impression that CONFIRM_TRANSACTION in case of cohesion does not include the process of composer  preparing inferiors in the confirm-set. If what you said is the case, isn't PREPARE_INFERIORS unnecessary?
 
The possibility of sponteneous prepare (which is normal with one-shots of course) means that even an atom coordinator may have no remaining first phase to run when it gets CONFIRM_TRANSACTION. It doesn't matter what made the PREPARED arrive - from the coordinator/composers perspective, the purpose of sending PREPARE is just to kick PREPAREDs out of confirm-set Inferiors that haven't delivered one yet.
[Cho, Pyounguk] Even when there is no inferior left to be prepared by coordinator, I guess the 1st phase happens implicitly(it just doesn't have to prepare any)  
 
Peter


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


Powered by eList eXpress LLC