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