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

[Mark Little <mark_little@hp.com>]

 

 

PF 2: The application logic has gone wrong - it's lost track of what inferiors it actually has.  I would most strongly advise writers of transactional applications to make the error path of their code cause the cancellation of anything it can cancel, rather than try to barge their way through.  And probably even more so for writers of intermediate abstraction layers  (which has less idea what's going on and ought to be even less likely to get its table in a twist)

Agreed, but if the driving force behind this is a workflow engine, for example, then compensations may already be in place via other inferiors that haven't been prepared yet. We should not be writing a specification on "loosening transactional capabilities" that requires an implementation (or user) to conform to a specific mode of operation.

There ought to be an exception catcher, certainly. And if that really wants to carry on, we have the mechanisms to interrogate the actual status (remember that inferiors can go prepared spontaneously anyway). But why must the decider implmentation be requried to produce a well-defined result to what was a garbled instruction.  The application (or abstraction) code is bugged.

But doing nothing in the first place keeps the system in a state that is easier to deal with from that failure point. I don't know if you are arguing from an implementation stand-point or purely from a conceptual point of view, but I really don't see why you would want to argue that, in the case of an error in a received parameter, an implementation of a cohesion should carry-on regardless and do the work on the other inferiors before returning an error. It doesn't make sense. Better to do nothing in the first place and let the sender deal with the parameter list in the knowledge that nothing happened at the coordinator.

 

Mark.

 

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