The AT specification’s specific use of InconsistentInternalState (IIS) fault is to indicate protocol violations that occur after it is no longer possible to change the outcome of the transaction; IIS is used in the PV table in the cells { Commit; Aborting } and { Rollback, Committing }.
The current definition of IIS does not correctly reflect its intended use. Hence, rewording its definition consistent with the aforementioned use:
"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 should throw IIS fault (instead of InvalidState) from the following cells:
Format: {Row; Column1, Column2}
1. {ReadOnly; PreparedSuccess, Committing}
2. {Aborted; PreparedSuccess, Committing}
3. {Committed; PreparedSuccess, Aborting}
This is identified as WS-TX issue 041.
Please ensure follow-ups have a subject line starting "Issue 041 - WS-AT: Invalid events should not cause defined transitions".
Issue name -- WS-AT: Invalid events should not cause defined transitions
PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER.
The issues coordinators will notify the list when that has occurred.
Target document and draft:
Link to the document referenced:
Section and PDF line number:
ws-at section 10, lines 503/505
coordinator table: Committed/Active, Committed/Preparing
pariticipant table: Commit/Active, Commit/Preparing
ws-at: seciton 6.1, line 371
The receipt of a message when the receiver is in a state such that the event cannot occur between correct implementations should not cause a state transition and allow the transaction to complete "successfully".
There is no need to distinguish "InvalidState" and "InconsistentInternalState".
InvalidState is defined in WS-Coordinator as being an unrecoverable condition, and in all the cases where it is a defined response in the WS-AT tables can only occur if one of the implementations is broken/bugged (apart than the volatile Prepared/None case, see separate issue). Providing a defined state transition, as if the circumstance were expected and could be recovered from is inappropriate. There can be no graceful completion of the protocol - it has gone fundamentally wrong. This does not preclude an implementation from attempting to tidy up and protecting its own resources, but there should be no required state transition for the implementation. The protocol exchange has gone off the map.
The use of InconsistentInternalState to distinguish two cases where an invalid event occurs is unnecessary (and the definition in line 371 does not align with the use in the table - it is probably the coordinator that has been sending wrong messages).
The use of InvalidState is appropriate in all cases.
The clearest solution would be to make invalid cells in the state tables empty, for the cells currently shown as InvalidState or InconsistentInternalState, and also for the N/A cells and explain this with text:
"Where a cell is shown as empty
- if the row is for an Inbound Event, an WS-C Invalid State fault should be returned. The subsequent behaviour of the implementation is undefined.
- if the row is for an Internal Event, event cannot occur in this state. A TM should view these occurences as serious internal consistency issues."
Having invalid cells empty makes it significantly easier to read and check the state tables. It becomes much clearer that they are essentially "sparse" and the path through the table can be followed more easily.