OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [bt-spec] BTP Issue 53 : will or may contradict ?

I've just realised that I've been answering a different question because I hadn't checked the original text. The original sentence is "The latter will cause a CONTRADICTION message to be sent", whereas we've been discussing whether it causes a mixed situation. Yes, it is possible, if somewhat tricky, to avoid the mixed situation. But there will *always* be a CONTRADICTION message sent down to this Inferior, which is needed to allow the Inferior to remove its persistent record of the autonomous decision (c.f. forget in OTS).
I suggest the text here be left as it is. If there is a need to explain the tricks to avoid mixed, it should be with the more comprehensive explanation of how decisions are made and recorded (where-ever that text gets moved).
 -----Original Message-----
From: Peter Furniss [mailto:peter.furniss@choreology.com]
Sent: 23 November 2001 01:35
To: bt-spec@lists.oasis-open.org
Subject: RE: [bt-spec] BTP Issue 53 : will or may contradict ?

Yes, assuming the CONFIRMs are sent out synchronously, waiting for the replies. That's not necessarily a good idea - if the first is slow to respond, the others have to hang on waiting to know the otucome. That might be ok in a closed environment, but would seem to be more iffy in the "more loosely coupled" environment we expect for BTP.
"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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC