Proposed AT CP state table

[Alastair Green <alastair.green@choreology.com>]

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

2006-07-12.AT.Completion.protocol.DRAFT.3.xls