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