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

[Mark Little <mark_little@hp.com>]

 

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.

 

Mark.

 

----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax  : +44 191 2606250