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

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

Pyounguk,

 

PREPARE_INFERIORS is only ever sent to a top-most composer or (if the suggestion is accepted) coordinator - that is from Terminator to Decider. It is never used on the Superior:Inferior links.

 

Atoms and Cohesions are basically the same in their behaviour - both when they are top-most - and so Deciders, driven by the application acting as Terminator, and even more so in the sub-co* form, when they are inferior to some other superior. The change proposed here would make them even more like. Considering the sequence on the terminator:decider relation

 

active phase: some Inferiors may spontaneously send PREPARED (this in fact will be understood and expected by the application, and perhaps even demanded via the application protocol, but to BTP it is spontaneous)

 

terminator may issue PREPARE_INFERIORS for some subset of the Inferiors  - question is whether this is allowed for coordinators as well as composers

 

terminator may issue REQUEST_INFERIOR_STATUSES - regardless of type

 

terminator may issue CANCEL_INFERIORS for some subset *but only to a composer*

 

those can be issued repeatedly, in any order.

 

eventually, terminator issues one of

 

CANCEL_TRANSACTION - cancels all inferiors and ends the transaction

 

 

CONFIRM_TRANSACTION

   if this is a cohesion composer, the inferiors-list parameter may be present, and the confirm-set is only the inferiors in it

   if the inferiors list is absent (which it must be for an atom coordinator, and can be for a cohesion composer) the confirm-set is all un-resigned inferiors.

 

CANCEL is sent to all inferiors not in the confirm-set (only applies for cohesions)

 

  if for any inferiors in the confirm-set, neither PREPARED or CANCELLED has been received and PREPARE has not been sent to it, PREPARE is now sent

 

  if (eventually) for all inferiors in the confirm-set set, PREPARED has been received, the list of inferiors is persisted. if this works, CONFIRM is sent to the inferiors of the confirm-set.

 

if any infeiror in the confirm-set sends CANCELLED, all the confirm-set is cancelled.

 

Important thing is the last three rules are identical - once the confirm-set is decided, the probability wave-function of the cohesion collapses, and it behaves atomically.

 

 

That works out that, if PREPARE_INFERIORS and CANCEL_INFERIORS aren't used, and there is no spontaneous prepare, the CONFIRM_TRANSACTION triggers all of the prepare wave, for atoms and cohesions.

 

So, yes, "the termination protocol is triggered by the applicaiton but carried out by the decider, which will pass the final outcome to the terminator", but that's true for both.  (and the application may start the PREPARE and PREPARED early, by various means)

 

Peter

 

 

 -----Original Message-----
From: Cho, Pyounguk [mailto:PCho@iona.com]
Sent: 25 January 2002 19:36
To: 'Peter Furniss'; bt-spec@lists.oasis-open.org
Subject: RE: [bt-spec] BTP Issue 52 : Forms of PREPARE

Hi Peter,

    Who can send PREPARE_INFERIORS to whom? Is it a message to be used between a coordinator/composer and its inferiors or between terminator(application) and decider? If the latter is the case, I do not have any problem.

 

    But, if this message is for coordinator-inferior relationship, let me ask you this question relating to a bigger question;who drives the termination protocol in case of atom? My understanding is that, unlike cohesion where the terminator performs 2 or n phase messaing via composer to produce the ultimate outcome of the transaction, atom's termination protocol is triggered by application but carried out by decider(coordinator), which will pass the final outcome to the terminator. Please, correct me if I'm wrong on this.

 

Thanks,

Pyounguk

-----Original Message-----
From: Peter Furniss [mailto:peter.furniss@choreology.com]
Sent: Friday, January 25, 2002 9:41 AM
To: bt-spec@lists.oasis-open.org
Subject: RE: [bt-spec] BTP Issue 52 : Forms of PREPARE

After talking about this with various people, it seems the resolution may now be clear due to issue 79, but it is also not what it should be.

 

There is no really strong reason why we do not allow PREPARE_INFERIORS to an Atom Coordinator. Although partial preparation can only everntually lead to general preparation and confirmation (or cancellation), the possibility of spontaneous PREPARED's arriving (triggered by application messages), and the availaibility of REQUEST_INFERIOR_STATUSES means that partial preparation is possible with an atom - just that (at present) the standard control relatinship don't allow it to be induced.   It's possible to imagine scenarios where an application want to force some Inferiors to determine if they could go to prepared state, before performing further work. It's more difficult to explain why you can't do it than to allow it.

 

The same argument does not apply to CANCEL_INFERIORS, since if one inferior is cancelled, they are all going to be, and the only possible next message is CANCEL_TRANSACTION.

 

If this is followed, then

 

Suggested solution:

 

Clarified by solution to issue 79

 

In PREPARE_INFERIORS, delete the phrase ", but only if it is a Cohesion Composer, " in the first line, and the two (Composer) after Decider..

 

Also change the description for the Coordinator in the role section (the lists of what is sent and received will be updated by issue 61)

 

 

Peter

-----Original Message-----
From: Peter Furniss [mailto:peter.furniss@choreology.com]
Sent: 17 January 2002 16:35
To: bt-spec@lists.oasis-open.org
Subject: RE: [bt-spec] BTP Issue 52 : Forms of PREPARE

 believe this issue was resolved by the agreed solution to issue 79 - with the normalisation of the message set the original ambiguity has gone:

 

 PREPARE is sent from Superior to Inferiors, whether they are Participants or sub-Coordinators (or sub-Composers)

 

 PREPARE_INFERIORS is sent from Terminator to Composer' (as a Decider)

 

There is no direct equivalent message sent from a Terminator to a Coordinator (as said in the November messages, if you want to prepare a Coordinator, presumably you want to confirm it, so you jump straight ahead to CONFIRM_TRANSACTION).

 

Proposed solution

Resolved by solution to issue 79

 

 

Peter

------------------------------------------
Peter Furniss
Technical Director, Choreology Ltd
web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N 2JX