[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-tx] Proposed AT CP state table
Bringing to the list the point I made in the side
discussion:
There is no transitory time window *on this table". When
the Commit Decision occurs, this table sends Committed and transits to None.
From None, it mandates sending UnknownTransaction. Whatever may be going on on
the 2PC relationships, on this relationship, the coordinator has no authority to
send a second Committed.
Remember an implementation is not required to
[internally] represent all the states and events known to the state table,
but it is mostly definitely constrained to only exhibit external behaviour (i.e.
send messages) consistent with the state tables.
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]