Re: [bt-spec] BTP Issue 99 : PREPARE_INFERIORS andFAULT(InvalidInferior)

[Mark Little <mark_little@hp.com>]

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.

 

I don't believe that it's pretty sure a CANCEL of the whole cohesion is going to happen just because I send a PREPARE_INFERIORS. I may be sending many such PREPARE_INFERIORS over a period of hours or days and not make a choice until much later as to how to end the cohesion. Or perhaps I've misunderstood what you meant.

 

 

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.

I disagree that there is little that can happen when a warning occurs. Whatever called PREPARE_INFERIORS (whether directly or via many layers of abstraction) had better expect that such an error can occur and to be able to deal with it. What I'm saying is that we can say at our level that "nothing will have prepared" if such an error occurs and that gives the higher-level abstractions and business logic a better footing from which to deal with the error than would otherwise be the case IMO.

 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.)

Agreed. This is purely a PREPARE_INFERIORS issue.

 

Mark.

 

----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax  : +44 191 2606250