[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-tx] Proposed AT CP state table
|
On point (a) below, yes, the Completion protocol diagram should be
updated to show the coordinator-generated Aborted transition from Active to
Ended state. I will open a new issue for this. One point (b) below: Yes, the accepted Completion protocol state
table does not prevent a coordinator implementation from doing so. Such a
coordinator behavior does not violate the protocol. But since the protocol does
not offer the guarantee that a coordinator will indefinitely retain the outcome
state, the client logic cannot rely on getting an Aborted or Committed response
from the coordinator. From: Peter Furniss
[mailto:peter.furniss@erebor.co.uk] Noting (and accepting) that the committee decided to use the table
Ram proposed,
a) we now have a mis-alignment between this table and the diagram
for the completion protocol. The diagram does not show a coordinator-generated
Aborted from Active state to Ended. Someone may want to raise an issue on this.
b) given the general interpretation rule for the tables that means,
even with this table, a coordinator implementation can choose
to return a repeat Committed or Aborted if it knows the state, it would
seem the behaviour Alastair proposed, of replying to a Rollback with Committed
(following an earlier Commit and CommitDecision) is also permitted. There was
objection to that idea in the discussion, but since we have chosen silence and
allowed implementations to send additional messages, there is nothing to
prevent it. Peter From: Ram Jeyaraman
[mailto:Ram.Jeyaraman@microsoft.com] Thanks Alastair. Here is the normalized state table that represents the
case where duplicate Commit or Rollback message would receive Unknown
Transaction. I believe that this does not prevent a coordinator implementation
from returning Committed or Aborted, if it chooses to, during the transitory
2PC time window.
-----Original Message----- Dear all, Ram and I have been working on the AT CP state table
issue, and I think we've converged to a considerable degree, but not fully. I'm attaching my proposal. There are two points outstanding between Choreo and
Microsoft: 1. Should a participant sending Aborted, leading to an
active state rollback (cell Rollback Decision/Active) induce a "Send
Aborted" action (not shown in my proposal)? This would mean that a CP participant would receive a
spontaneous Aborted outcome message before it had sent Commit or Rollback to
the coordinator. I do not object to this per se, but am worried that this turns
a request-response model into a full one-way model, which would preclude a thin
client implementation of a CP participant (on which point I have raised a
separate issue). 2. Should the state table show Committing and Aborting
states, allowing a precise response (Committed or Aborted) to be returned
during the processing of the 2PC protocol across the underlying participants?
This is the approach in my proposal. Ram, I believe, accepts that it is legitimate for an
implementation to do this (our product does so), but thinks that the transition
to state None should occur immediately that Aborted is received, or internal
event Commit Decision arises, thereby removing the Committing and Aborting
states in the proposed table. This would mean that any duplicate Commit or Rollback
message would receive Unknown Transaction. If I can be persuaded that this
approach does not prevent returning Committed or Aborted after the None
transition (i.e. that the implementation was free to communicate outcome
knowledge if it happened to still have it) then I would be happy with that, but
I believe that this approach would in fact make that illegal (because contrary
to the state table). Yours, Alastair |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]