RE: [ws-tx] Proposed AT CP state table

I think the completion participant has two responsibilities:

To vote on the outcome of the transaction.
To ensure that (in the case of a ‘commit’ vote) transaction completion does not race with active work.

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]
Sent: Monday, July 17, 2006 4:34 AM
To: Peter Furniss
Cc: Ram Jeyaraman; ws-tx@lists.oasis-open.org
Subject: Re: [ws-tx] Proposed AT CP state table

Peter,

These are important points you have raised.

On a) I believe that sending Aborted spontaneously is an unhelpful innovation: I did raise this point in writing and in the discussion, but it got short shrift in the discussion (I'm not sure anyone else addressed it all). This new behaviour prevents (or complicates) the writing of thin demarcating clients. It changes existing implementations.

On b): "objection" is perhaps a mild term. Max described the notion of replying to a Rollback with a Committed as "frivolous" and "deeply concerning" in the chat room.

I find this odd. Our chief concern is correctness. Within that framework, being informative is helpful and good. If I send Rollback and receive Commit then I know one of two things: either that I have previously sent Commit (i.e. that my application client has committed a logic error), or that some other CP participant has done so. If I receive Invalid State then I know either that my interlocutor is bugged in some odd way, or that I or another participant has previously sent Commit. Where is the information loss? Why is this "frivolous"?

If as Peter says, it is deemed (in line with Microsoft's motivating text and argumentation) that the new state table does not prevent communication to the participant of knowledge of the fact of having made a commit decision, or the fact of having been instructed to abort or having made an abort decision -- despite having nominally moved to state None -- then the implementation presumably can send Committed in response to Rollback. There is nothing in the spec to stop that happening. Nor is there anything in the spec to permit or prevent the sending of Invalid State.

On an alternative interpretation (the only sensible one of a reader coming cold to the spec), it is forbidden to send the actual outcome because the state None must be responded to with Unknown Transaction, even if the transaction is in fact still known.

This is not frivolous, but it is a mistake. If a participant sends Commit, and receives no response, then it may retry Commit. If the first message did get through, and the response was lost, then he will now receive Unknown Transaction.

In designing an API for completion, there are some obvious things you can do to maximize the chance of the client knowing the outcome, as long as the protocol is able to support replay of the outcome message. To take one obvious example: remember the outcome at least as long as the transaction timeout. This is now precluded, in my view.

The outcome of this decision of the TC is to render the Completion Protocol fuzzy and different, which is not good news for interoperation.

Alastair

Peter Furniss wrote:

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

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.

			Completion protocol (Coordinator View) [New]
	States
Inbound Events	None	Active	Completing
Commit	UnknownTransaction None	Initiate User Commit Completing	Ignore Completing
Rollback	UnknownTransaction None	Initiate User Rollback, Send Aborted None	InvalidState Completing
Internal Events
Commit Decision	N/A	N/A	Send Committed None
Abort Decision	N/A	Send Aborted None	Send Aborted None

-----Original Message-----
From: Alastair Green [mailto:alastair.green@choreology.com]
Sent: Thursday, July 13, 2006 7:31 AM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] Proposed AT CP state table

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

ws-tx message