[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC