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

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

Greetings Pyounguk,

 

I'll cut to the chase ...

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?

 

PRF: No, under REQUEST_TRANSACTION (which is what this was), in 0.9, it used to say:: 

 

"If PREPARED has not been received from any Inferiors in the confirm-set, PREPARE shall be issued to them.  "

 

PRF:  that could be read as meaning "if PREPARED has been received from none of the Inferiors, PREPARE shall be issued to all of them", and if anyone did, they'ed be quite confused.  But it was changed in resolution of issue 20 to say

"If, for each of the Inferiors in the confirm-set, PREPARE has not been sent and PREPARED has not been received, PREPARE shall be issued to that Inferior. "

 

PRF: (and the preceding, unchanged, text has just explained what the confirm-set is). That was intended to be a clarification - the intent was unaltered. Issue 79 resolution did nothing other than change the name of the message (REQUEST_CONFIRM, unusually, was already normalised)

 

 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)  

 

PRF: That seems a bit Zen !  (the sound of PREPARE being sent to no Inferiors ?). Yes, an implementation might do something like that - loop through seeing if PREPARE needs to be sent to anything, then loop through seeing if PREPARED has been received from everything; if not, wait until something turns up, then repeat the second loop.

 

Peter