RE: [bt-spec] Issue 67: "Hazard" from autonomous decision

I've put in a proposed solution that is the same as Tony's except for the meta-text of what the change is, and I've made the sentence "Note that" into an explanatory note.

Peter

The BTP spec (version 0.9.1.3) in the section "Roles involved in the outcome relationships", sub-section "Superior" says: This outcome can be confirm only if a PREPARED message is received from the Inferior, and if a record, identifying the Inferior can be persisted. (Whether this record is also a record of a confirm decision depends on the Superior’s position in the business transaction as a whole.). The Superior must retain this persistent record until it receives a CONFIRMED (or, in exceptional cases, CANCELLED or HAZARD) from the Inferior.

The same section, sub-section on Inferior states:

An Inferior that has become prepared may, exceptionally, make an autonomous decision to be applied to the associated operations, without waiting for the Outcome from the Superior. It is required to persist this autonomous decision and report it to the Superior with CONFIRMED or CANCELLED as appropriate. If, when CONFIRM or CANCEL is received, the autonomous decision and the decision received from the Superior are contradictory, the Inferior must retain the record of the autonomous decision until receiving a CONTRADICTION message.

The state tables support this. I can not see that sending HAZARD is allowed after an autonomous decision to confirm or cancel.

However, the text for the HAZARD abstract message states:

Sent when the Inferior has either discovered a “mixed” condition: that is unable to correctly and consistently cancel or confirm the operations in accord with the decision (either the received decision of the superior or its own autonomous decision), or when the Inferior is unable to determine that a “mixed” condition has not occurred.

Peter explains:

The main purpose of HAZARD is to be used *after* PREPARED has been sent, to indicate that things have gone wrong. It was also allowed to be used where things have got horribly stuck before becoming prepared, such that the inferior can't cancel either. (I've never been very happy about that one - it doesn't seem to have been needed in other transaction protocols)

The state tables do allow that - inferior can transit from e* to p2 and from the active states There's a curiosity that needs explaining in the p* states - they can send HAZARD or record the problem (transit to q1) - inferior should try to record and only send HAZARD if it can't record.

What the tables don't allow at present is transit to p* from any of the decided states. The thinking there was that the autonomous decisions and the "decision" to apply an ordered confirmation were, by definition, "clean" - if an inferior only makes an autonomous decision to cancel (say) by the act of cancelling the operations; if it can't cancel cleanly, then it has generated a mixed condition and hasn't made an autonomous cancel decision after all.

So that's really a modelling answer. If you take a different approach - which would mean treating the autonomous decision as something separate from its application, then you get some complications with the message sequence. After taking the autonomous decision, it would now be in a state of applying it, and then seeing if it worked (actually there'd be a separate event,which was apply-autonomous-decision. Otherwise you get two termination messages.

To summarise: If an Inferior can not come to a prepared state and also can not cancel its operations reliably (or is also a superior and receives Hazard from one, or more, of its inferiors), or has entered the prepared state and something goes wrong, then it sends HAZARD to its superior. If it makes an autonomous decision then it signals that decision, which can only be CONFIRMED or CANCELLED. When it makes an autonomous decision it must persist this information. If its result is the same as that of the transaction as a whole then it will receive a CONFIRM or CANCEL message as confirmation and can then delete the persisted information. If its decision was different then it will receive a CONTRADICTION message. It can use this as the signal that it may delete the persistent information (it certainly does so as far as the BT protocol is concerned but may move it to some other log for error checking purposes) and it may locally flag that there was a problem.

So - no HAZARD is not sent after an autonomous decision (but as that decision is internal to the Inferior, if something goes wrong after taken the decision, but before communicating externally, it could invisibly go back on the decision, pretend it never made it, which to external view it did not, and send HAZARD).

Proposed solution:

Change the text for the HAZARD message to read:

Sent when the Inferior has either discovered a “mixed” condition: that is, it is unable to correctly and consistently cancel or confirm the operations in accord with the decision received from its superior ), or when the Inferior is unable to determine that a “mixed” condition has not occurred. Note that if the Inferior makes its own autonomous decision then it signals this decision (CONFIRMED or CANCELLED) and waits to receive a confirmatory CONFIRM or CANCEL in reply, or a CONTRADICTION if the autonomous decision by the Inferior was the opposite of that made by the Superior.

Choreology Ltd., 13 Austin Friars, London EC2N 2JX UK

Tel: +44 (0) 20 76701787 Mobile: +44 (0) 7801 948219

tony.fletcher@choreology.com (Home: amfletcher@iee.org)

bt-spec message

Issue 67: "Hazard" from autonomous decision ?