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 ?


 
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.
I disagree. At the end of the day a specification is no use if it cannot be implemented, and providing hints to assist such implementations is something we should be doing.
 
Mark.
 
----------------------------------------------
Dr. Mark Little
Transactions Architect, HP Arjuna Labs
Email: mark@arjuna.com | mark_little@hp.com
Phone: +44 191 2064538
Fax  : +44 191 2064203
 
 


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


Powered by eList eXpress LLC