[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-tx] Proposed AT CP state table
Max,
The point of my comment b) was not so much whether the
Rollback - Committed exchange is desirable, but that the decision made last
week means that the replying to Rollback with Committed (after commit decision)
is just as permissible as replying with to Commit with Committed (at the same
point). By choosing silence, the spec does not forbid one if it allows the
other. By the interpretation of the tables everyone else has, the latter is
permitted (not required), as you describe below; ergo the first is permitted. By
my preferred interpretation of state tables, both would be
forbidden.
Peter
From: Max Feingold
[mailto:Max.Feingold@microsoft.com]
Sent: 18 July 2006 18:06 To: Alastair Green; Peter Furniss Cc: Ram Jeyaraman; ws-tx@lists.oasis-open.org 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]