Alastair,
On the issue of duplicates:
A nervous client may send a jittery
sequence of “Commit, Commit, Rollback, Commit, Rollback, …”
message sequences; Or network retransmissions, as you point out, may result in “Commit,
Commit, Commit, …” or “Rollback, Rollback, Rollback, …”
sequences, or worse still, a malicious DOS attack may spew forth an unending
sequence of “Rollback” and “Commit” messages!
Clearly, the first message to arrive at
the coordinator wins; consequently, the coordinator sets the 2PC/Rollback
freight train in motion which never stops for a reason, except if it crashes on
to an obstacle. More importantly, the coordinator state immediately moves away
from an “Active” state to either “Preparing” or “Aborting”,
upon reacting to the first successful “Commit” or “Rollback”
message. Any subsequent “Commit” or “Rollback” message
that arrives at the coordinator has lost the chance to influence the outcome,
since the coordinator has already moved on to “Preparing” or “Aborting”
state upon the receipt of the first successful “Commit” or “Rollback”
message.
It is unsafe for an implementation to react
to such potentially malevolent duplicate messages. Handling of duplicates can
be best left to an implementation to deal with, and is probably not crucial for
interoperability.
From: Alastair Green [mailto:alastair.green@choreology.com]
Sent: Friday, May 19, 2006 2:57 AM
To: Ram Jeyaraman
Cc: ws-tx@lists.oasis-open.org
Subject: Re: [ws-tx] Issue 055 -
WS-AT: User Commit and User Rollback should not return Aborted in None state
Ram,
I think your proposal is narrowly good, but is broadly unsatisfactory. It
pushes the issue of duplication away from the state table (the state table can
be insulated), but it leaves unanswered how duplication in the Completion
protocol is to be handled. As that protocol is interoperable its behaviour in
the face of duplication cannot be left to implementations, as I think you
imply. If we do that then your proposed solution would evade a larger issue.
See below for more on this.
A general review of the names of the events would be a good idea. They are far
from intuitive (e.g. All Forgotten equals Read Only Decision). They also need
to be defined, so that there is
no doubt or ambiguity about what they mean. (Issue 048).
On your names: Commit Requested is correct -- the request may not be satisfied.
Rollback Instructed might be more appropriate: it's an order unless it is
played out of sequence (after a commit request).
You could also change the Completion protocol message names to RequestCommit
and InstructRollback in line with this. This would avoid the overload between
the Completion protocol and the 2PC protocol. They really don't mean the same
thing. The Completion protocol participant is distinct and privileged: it is
the only participant able to spontaneously "prepare" or
"abort".
* * *
Completion protocol duplication
I fully understand the idea that we define these two internal events to be able
to occur once only, which the state table change does. This protects the state
table from duplicate messages. Screening out duplicates at this level
(protection of the state machine) is an implementation issue. Incidentally, the
state table is not protected against a Commit followed by a Rollback. Unless
that sequence is prohibited somewhere, it is allowed. And as the completion
protocol is optional (I assume) we can't rely on that to define the possible
sequence
My question related to the response given by a Completion Coordinator if it is
presented with a repeated outcome message (Commit, Rollback). The old line in
the 2PC state table indicated that replays of response semantics could occur
under certain circumstances.
Now we have no statement whatsoever. Your reorganization of the state table
defers or displaces the problem raised by this issue to the externally visible
interoperable protocol where duplication can occur. This is analogous to the
discussion on duplication in WS-Coordination: we cannot assume this away.
Does a conformant implementation refuse to recognize duplicates (very odd,
messages may be lost in both directions, and messages may be duplicated at the
transport level), or does it replay responses? Furthermore, if a duplicate
arrives after the coordinator has gone to None, we still need to know how to
respond, which I think still requires Unknown Transaction (an interoperable
message). The old state table showed replaying of responses in all of these
circumstances, but played the wrong response (Aborted) in the None case.
This discussion is therefore a combination of this issue 055 and the closely
related issue 056. Your proposed resolution of 055 is fine as far as the state
table is concerned, but we can't sweep the issue of the Completion protocol
under the carpet.
Alastair
Ram Jeyaraman wrote:
Alastair,
We should rename the "User Commit" and "User Rollback" internal events
to "Commit Requested" and "Rollback Requested", since these events are
fired exactly once, even though there may be erroneous or duplicate
Completion protocol messages.
Beyond that, it is not necessary to model the handling of erroneous or
duplicate messages; it is an implementation detail. The expectation is
that a Completion protocol message received during the Active state
would fire an internal event "Commit requested" or "Rollback requested"
exactly once.
-----Original Message-----
From: Alastair Green [mailto:alastair.green@choreology.com]
Sent: Thursday, May 18, 2006 4:13 AM
To: Ram Jeyaraman
Cc: ws-tx@lists.oasis-open.org
Subject: Re: [ws-tx] Issue 055 - WS-AT: User Commit and User Rollback
should not return Aborted in None state
Ram,
I think that is correct, and is a good solution to this issue.
You (correctly) say that repeated transmissions of Completion protocol
messages cannot be avoided or prevented.
How should a Coordinator respond to such retransmissions when receiving
duplicates from a Completion protocol Participant? The proposed change,
while cleaning up in a good way, now makes it less clear what should
happen in this respect, as there is no interaction or overlap between
the 2PC state table, and the CP state diagram -- which does not show how
duplicates would be handled.
Alastair
Ram Jeyaraman wrote:
The CV 2PC state table currently treats the User Commit and User
Rollback as inbound events, instead of as internal events. An internal
event triggered as a result of a Completion protocol would fire
exactly
once during the Active state. If such an *internal* event occurs
during
other states, it indicates an internal failure; it should not happen.
Note this does not mean that the participant of a Completion protocol
cannot resend messages or send messages in incorrect sequences; only
that such erroneous or duplicate messages would not trigger an
internal
event (User Commit or User Rollback) that kick-starts the 2PC
protocol.
Please find attached a modified table that illustrates the
aforementioned behavior; that is, the internal events (User Commit and
User Rollback) has valid state transitions only for the Active state.
-----Original Message-----
From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
Sent: Thursday, April 06, 2006 10:54 AM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] Issue 055 - WS-AT: User Commit and User Rollback
should
not return Aborted in None state
This is identified as WS-TX issue 055.
Please ensure follow-ups have a subject line starting "Issue 055 -
WS-AT: User Commit and User Rollback should not return Aborted in None
state".
-----Original Message-----
From: Alastair Green [mailto:alastair.green@choreology.com]
Sent: Wednesday, April 05, 2006 5:14 PM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] New Issue: WS-AT: User Commit and User Rollback
should
not return Aborted in None state
Issue name -- WS-AT: User Commit and User Rollback should not return
Aborted in None state
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:
Protocol: WS-AT
Artifact: spec
Draft:
WS-AT CD 0.1 uploaded
Link to the document referenced:
http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17325/ws
tx-wsat-1.1-spec-cd-01.pdf
Section and PDF line number:
Section 10, "State Tables", Coordinator View table, between ll. 503
and
504
Issue type:
Design
Related issues:
New Issue: WS-AT: User Commit and User Rollback row of CV state table
contradicts resolution of 010
Issue Description:
If transaction in state None, and event User Commit or User Rollback
arises, then action is to Return Aborted (aka tell application that
the
transaction was aborted). In fact transaction may just have been
forgotten, and may either have been aborted or committed. Return value
possibly contradicts reality, therefore.
Issue Details:
All Forgotten event arises when all participants have done action
Forget. If this happens when transaction as a whole is in Aborting or
Committting state then the state flips to None.
User Commit or User Rollback event may then arise. (Replay of
Completion
protocol Commit, API replay). Response of coordinator state machine is
to process action "Return Aborted". See WS-AT Coordinator View state
table, rows (Internal Events) User Commit and User Rollback, which
read
as follows:
User Commit/None: Return Aborted --> None
User Rollback/None: Return Aborted --> None
Clearly this information may be false. It is possible that we got to
None via Committing, or via Aborting. The result was either Committed
or
Aborted. Naturally, if we have gone "All Forgotten" we have literally
... forgotten which it was.
Proposed Resolution:
a) Amend state table cells referred to in problem description to read:
User Commit/None: Return Unknown --> None
User Rollback/None: Return Unknown --> None
b) Define new fault for use by Completion protocol, called
UnknownOutcome, which can be returned if this happens.