[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-tx] Proposed AT CP state table
I think the completion participant has two
responsibilities:
A completion participant that changes its mind
on the outcome it wishes to see is no different than a volatile participant
doing the same. This is a protocol violation. That is why I believe
that replying to Rollback with Committed is wrong – it implies that the
completion participant already voted to commit, but has now changed its mind. … In designing an API for completion that
works against generic WS-AT implementations, a completion participant that
resends Commit cannot rely on receiving accurate responses to Commit resends,
given the volatility of the protocol and the short window in which the
transaction outcome is generally known. Your own implementation is free
to implement your desired lingering behavior, but your participant-side
implementation has to be prepared to deal with UnknownTransaction faults if
you’re going to resend Commit against generic coordinators. If your client-side API needs to _reliably_ know the outcome, it should
implement a durable 2PC participant as well as a completion participant.
But in general, completion APIs tend to be best-effort, since the outcome
reported to the application is generally best-effort and does not affect
consistency. From: Alastair Green [mailto:alastair.green@choreology.com] Peter, 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]
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]