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


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