"may" makes the statement rather too weak - it really is a very
special case that an wrong autonomous decision doesn't produce a
contradiction.
Suggestion: just add "usually" in "latter will usually cause a
CONTRADICTION"
We should
not be assuming anything about the environment in which BTP will "typically"
be used. As a result, it's not an objective statement to say it's a "very
special case", since that in itself is based on certain assumptions about
deployment. I don't mind "usually", but what I do want is some text along the
lines of:
"If the
coordinator is issuing the second phase of a successful (i.e., CONFIRM)
completion protocol synchronously, then it is possible upon the receipt of a
CANCEL message from the first non-RESIGNED participant for the
coordinator to change it's decision to CANCEL the atom, and in such a way
prevent a CONTRADICTION from occurring. Otherwise ..."
I
would like to avoid contradictions as much as possible, because cleaning up
after them is going to be a nightmare for system administrators, especially if
they are spread across the planet. It's exactly the same argument as for this
kind of optimisation in TPs with heuristics.
I agree in general
about not assuming the environment of BTP is known - we have
avoided "usually" and "typically" in other places.
But in this case it
is an implementation construct that makes contradiction avoidance
possible at all. This text is only in a note to advise on how what is
going on, and I fear we are begging more explanation that is justified - we
should now explain "synchronously", since it's not used anywhere else, and has
to refer the sequence of sending CONFIRM to the remaining Inferiors - and even
that there is a sequence (otherwise "first ... participant" doesn't have
meaning). And if the coordinator also has other resources that are not
connected via BTP (such as local resources), they must not have been told to
confirm or commit (or there is some way of undoing them). And this has
got to be the top of the confirm tree, so it can change its mind. This sort of
stuff is ok to do in an implementation when you are sure exactly what is going
on, but I think it muddies the point of the sentence in the first place to
explain when contradiction can be avoided. I'd rather remove the
"latter will cause a CONTRADICTION" sentence than have to put in 8 times the
text to explain the exception.
Peter