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

["Ram Jeyaraman" <Ram.Jeyaraman@microsoft.com>]

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