bt-spec message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [bt-spec] Issue 67: "Hazard" from autonomous decision
- From: Tony Fletcher <tony_fletcher@btopenworld.com>
- To: BT - spec <bt-spec@lists.oasis-open.org>
- Date: Fri, 15 Feb 2002 11:49:03 +0000
Dear
Colleagues,
Tony
Fletcher:
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:
If an Inferior is unable to
come to a prepared state, it cancels the associated operations and informs the
Superior with a CANCELLED message. If it is unable to either come to a prepared
state, or to cancel the associated operations, it informs the Superior with a
HAZARD message.
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.
Best Regards
Tony
A M Fletcher
Choreology Ltd., 13 Austin Friars, London
EC2N 2JX UK
Tel: +44 (0) 20
76701787 Mobile: +44 (0) 7801
948219
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC