That's basically reasonable, but there is no need
to impose it on all implmentations. For safety, in the confirm case, the
implementation must check before it confirms, but there is no similar
requirement in the other cases. In fact, the other two are really just
packaging of "prepare-one-inferior" and
"cancel-one-inferior" allowing multiple
targets.
For CANCEL I don't think we need to check. However,
for PREPARE I'm not persuaded yet. The business logic has decided that it
wants to prepare a set of inferiors and has assembled that set, though one of
them is invalid. Now maybe we aught to be asking how this is possible, but if
we ignore that for now, I think it is reasonable to assume that the prepare
set has been assembled for some specific reason. If I scr*w up when making
that set it may well affect my choice of the set in the first place, i.e., if
I know that id 1234 is invalid then I may very well not have assembled it
*and* 6789 5678 ... into the prepare set in the first place - my prepare set
may very well be completely different.
Now, if I can't check until I've sent the
PREPARE_INFERIORS message and when that tells me I scr*wed up all of the other
inferiors are prepared, I've got to go and cancel them and then do something
else. I'd prefer the ability to know that nothing happened in the first place
(it's as though I didn't send the PREPARE_INFERIORS and invoked some
CHECK_INFERIORS message instead).
PF: Surely the case can only arise
when there is an error in the application logic - the terminator isn't
really intelligent, it's a program, even if we do tend to talk about it as
if it were sentient :-). It's pretty much a certainty that the next
thing is going to cancelling the whole cohesion, in which case it doesn't
matter what prepared anyway. If the application program for some
(unwise) reason wants to carry on and try to find a set of inferiors it wants
to confirm, it wouldn't have to cancel the ones that did prepare -- though a
REQUEST_INFERIORS_STATUS to find out what's really down there would be a good
move.
PF: My concern was
to avoid forcing an implmentation to scan through the list to check, when
there is very little use that can be made of the warning, and when the warning
shouldn't happen anyway. Of course, defensive system programming might suggest
the implmentation should check, but writing that into the standard is a
different matter. (The concern doesn't apply in the confirm case, because the
coordinator has to scan through the list anyway to work out what to
do.)
PF: Any one else
want to come in on this ?
Peter