|
Ram,
I don't think we agreed that the distinction between before
and after "possible to change the outcome" is
a) valid in all cases
b) even if valid for an omniscient observer,
determinable from the state of a single state machine
You have asserted the distinction, but in the case of
implementations violating protocol, there is no certain knowledge of the states
of the parties, or of transaction as a whole, given the state tables as they
are.
The existing uses of IIS (sent by Participant) certainly do
not reflect the meaning you propose. If a participant in Aborted or
Committing receives the wrong message, it is impossible to know if the
participant has illegally transitted to its current state (which would mean the
outcome was now fixed) or if the coordinator sent the wrong message earlier or
the coordinator sent the wrong message now.
The new uses you propose could be said to fit your new
definition, if we assume the coordinator is not the guilty party, but the
information is not worth distinguishing at the participant (which, if we make
the considerable assumption that the illegal message it has just sent reflects
its state, has already released its data in the wrong state). But that is a
major assumption - why should it be thought the participant meant what it said
at all.
I think we should admit that the original intent of IIS was
almost certainly to be indication that the participant had applied a decision to
its application work while it was awaiting the real outcome from the
coordinator, and this decision was intended to be reflected in a state change in
the participant state machine (to Aborting or Committing as appropriate).
With those assumptions, it is entirely reasonable that there is a different
fault returned from the {Commit; Aborting} and {Rollback;Committing} states. The
error would not then be a random bug, but a controlled and definable violation
of the intended contract. The definition would still need tweaking, and (on my
view of what state tables are about) we should define the transitions as
triggered by an internal event.
Of course, the procedural downside of this solution is that
the autonomous application of the decision is a heuristic decision, and the
different fault sent in this case is a signal of that heuristic (not the same
kind of reliable heuristic reporting as exists in OTS or OSI TP or earlier,
since there is no reply). But, personally, I'd have no problem with
clarifying the charter statement as excluding the reliable heuristic reporting,
while allowing the defination of the state transitions that reflect a heuristic
decision (it is impossible to forbid heuristic decisions in real life) and a
distinct fault to indicate that such a transition has
occurred.
Peter
Alastair, > What is so special about this bug, that it requires its very own fault type?
The
Inconsistent Internal State fault distinguishes the fact that a protocol
violation has occurred after it is no longer possible to change the outcome of
the transaction.
As we
know, the Inconsistent Internal State fault is already defined in the
specification (albeit the original definition does not quite convey its intended
purpose), and has currently been implemented and being used in
practice.
The
proposed resolution described below, merely clarifies its original intended
meaning:
This fault is sent by a participant or coordinator to indicate
that a protocol violation has been detected after it is no longer possible to
change the outcome of the transaction. This is indicative of a global
consistency failure and is an unrecoverable condition."
Further, the cells in the CV table need to be throw Inconsistent
Internal State fault.
1. {ReadOnly; PreparedSuccess, Committing}
2. {Aborted;
PreparedSuccess, Committing}
3. {Committed; PreparedSuccess, Aborting}
Note to Editors: Replace the use of InconsistentInternalState
fault with Inconsistent Internal State in all occurrences in the
specification.
From:
Alastair Green [mailto:alastair.green@choreology.com]
Sent: Tuesday,
August 08, 2006 5:52 AM
To:
ws-tx@lists.oasis-open.org
Subject: [ws-tx] [Fwd: Issue 041:
Inconsistent Internal State]
Third reposting
-------- Original Message --------
Inconsistent Internal State is defined thus: "This fault is sent by a participant to indicate that it cannot fulfill its obligations. This indicates a global consistency failure and is an unrecoverable condition." It is only used, in fact, to mean: "Coordinator has already instructed participant to Commit or Rollback, but is now saying the opposite". This is a condition that simply cannot arise, other than by bug. A 2PC coordinator cannot change its mind once it has issued an outcome message. What is so special about this bug, that it requires its very own fault type? Alastair
|