This is stated tersely in the abstract message descriptions
(after the parameter lists, with a note about cancel_inferiors/all ), and
better explained in the model section that covers evolution of the
confirm-set, for which my skeleton is:
which looks
like it's going to come out as a state diagram (and perhaps needs a little
tweaking to cover spontaneous PREPARED, CANCELLED, RESIGN in the "active"
phase)
However, this doesn't address the issue of all
inferiors resigning or cancelling for prepare_inferiors. In a traditional
transaction system (and presumably for atoms), if I issue a prepare and get
back cancel/readonly from all participants, I don't have to send anything else
to that transaction because I know it has finished. With cohesions, as I
mentioned earlier, the situation is different. In some cases I'd like
implementations to be able to free up resources held by the coordinator
implementation immediately simply because there won't be any other
registrations *and* the application shouldn't have to explicitly terminate
such a cohesion which now has no members.
PF: yes, the "tweaking" needs
to include the automatic completion of an atom in case of cancel and some
other stuff. With a cohesion, I think this comes down to wanting to delegate a
completion rule down to the coordinator implementation. It's already possible
for the terminator to do this in one case - if it knows what the confirm-set
would be, even if some of the inferiors in it haven't prepared yet (e.g. if
this cohesion is to confirm, it must include exactly inferiors A, D and E as
confirming or readonly) it can issue CONFIRM_TRANSACTION, which will run the
prepare phase where needed. In the case you're positing, the terminator can't
yet say that, so presumably it would find some combinations of prepared
inferiors acceptable, but there must be at least one un-cancelled inferior.
But that looks rather like just a particulat case - for some cohesions it
might be at least two, for others one particular inferior is essential, for
others various complex combinations. I doubt if it's worth complicating things
for the automated resource freeing in what must be a fairly unusual case (a
self-emptying cohesion must surely be a bit unusual for any
application)
Peter