[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-tx] Proposed AT CP state table
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]
Sent: 13 July 2006 16:09 To: Alastair Green; ws-tx@lists.oasis-open.org Subject: RE: [ws-tx] Proposed AT CP state table 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]