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)
Actually the situation I'm considering is more
specific than this: the driver of the cohesion knows that the lifetime of the
cohesion as far as enrolling participants is concerned is about to end when it
starts a specific prepare_inferiors, i.e., no more inferiors will be enrolled
(or at least by any of its own actions). If prepare_inferiors says everything
prepared then it will either decide to confirm or cancel them later. (It does
not know which way it will jump until after issuing prepare, so it can't call
confirm_transaction or cancel_transaction). So, if all of the inferiors say
they have cancelled the coordinator factory/manager implementation should be
able to release those resources since a cancel_transaction is superflous.
Likewise, if they all say resigned.
PF:
So it would primarily be a "no more enrols allowed" signal. I agree the
scenario is feasible, but since the only cost is the coordinator holding
on to internal resources, or the message exchange to clear it, and it only
makes a difference if the cohesion has emptied, I rather doubt if its
worthwhile.The counterbalancing cost is in specifying, implementing, testing,
explaining and documenting the feature.
As
always, non-standard control APIs could do more. Or a qualifier (std or not)
on prepare_inferiors, cancel_inferiors (or even on request_inferiors_status, I
guess)
Peter