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


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.

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.

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

        Atomic protocol
        1) allows a terminator to ask the status of the participants before CONFIRM_TRANSACTION messages is sent.
        2) once the CONFIRM_TRANSACTION message is sent to the coordinator, terminator cannot interfere with execution of the termination protocol
        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.

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.

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 :)

 
Peter
 
 
 -----Original Message-----
From: Sazi Temel [mailto:sazi.temel@bea.com]
Sent: 26 January 2002 17:24
To: Sanjay Dalal
Cc: Mark Little; Peter Furniss; bt-spec@lists.oasis-open.org
Subject: RE: [bt-spec] BTP Issue 52 : Forms of PREPARE
Sanjay, Mark and Peter,
I should jump in here since I was the one who mentioned this in a conversation with Peter, I thought could be a good idea to have this capability, I think I thought it was a capability of open-top coordinator... anyway, I do not see strong requirement for this feature, so we can conclude this thread: we all agree not to have PREPARE_INFERIORS to be sent to atom coordinator.  Do we still have the capability of Initiator/Terminator asking the status of Atom? I thought we had this but not sure now, can anyone clarify it?

Thanks.
--Sazi

At 07:13 AM 1/26/02 -0800, Sanjay Dalal wrote:
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.
I disagree. It's easy to say why we don't support it for Atoms: they are atomic! Cohesions aren't. If we go back to overloading messages then what was the point of normalisation?! At this stage I would prefer we leave well alone and do not allow PREPARE_INFERIORS on an atom - only on a cohesion. OK, some inferiors may be prepared early by downstream messages coming into the atom, but that's different from allowing it to happen from upstream. And there will always be cases where something might be "neat" to have, but at this stage in the game I think not.
 
 
I completely agree with Mark on this. This message, PREPARE_INFERIORS, just blows up atomicity of atoms. The so-called "open top atom coordinator" concept only applies if Cohesion is a Decider.
 
sanjay
 

Sazi Temel
'                               
bea Systems Inc.        
140 Allen Road  Liberty Corner, NJ 07938
        
sazi.temel@bea.com
sazi.temel@ieee.org
(1) 908 580 3123        
http://www.bea.com

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


Powered by eList eXpress LLC