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.
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