Re: [bt-spec] BTP Issue 105 : Qualifier to allow automatic completionof all-cancelled cohesions

[Mark Little <mark_little@hp.com>]

 

I am not convinced that this is a worthwhile change and therefore would propose a solution of 'No Change'.

 

Firstly I do think a qualifier should be used for something that changes the state and allowed sequence of messages - and the proposed change clearly does.  So if we were to adopt this change then it should be a proper parameter not a qualifier.

 

But frankly this kind of delegation does not seem very wise to me (i.e. is it really good defensive programming practice?).   An application could easily find that a cohesion it thought was still live has been blown away or conversely that one that it thought the decider would blow away because all inferiors had cancelled is actually still live because an inferior remains.  Thus it seems much safer to me to use an explicit CANCEL_TRANSACTION. 

I disagree for all of the issues mentioned in previous emails. Your "argument" about a cohesion going away when an application thought it should still be around seems more akin to saying "if I use the protocol wrongly I'm going to get screwed"! Which is pretty obvious! Where does the qualifier come from in the first place if not from the application or business logic driving this thing?!

 

This qualifier does change the state, or isn't going from "running" to "terminated" a state change? How would all of the other qualifiers already defined fit into your definition of what a qualifier should be? Is this definition in the specification?

 

Mark.

 

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