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,
    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



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


Powered by eList eXpress LLC