OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-tx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-tx] Issue 036 - WS-AT: Coordinator state machine - draft of revised tables


Attached are an excel workbook and word document containing and describing a draft for revised state tables for the WS-AT coordinator. As suggested in Issue 036, these distinguish the state of the multi-branch, node entity that has a lifetime of the transaction, and the coordinator endpoint entity that deals with a single participant.
 
The workbook contains 5 tables - coordinator-node, coordinator-2pc-endpoint, coordinator-completion-endpoint, participant and obsolete-restyled-coordinator. The last two are just the cd tables modified with the formatting changes I've used in the new tables. (In the "obsolete" coordinator table I didn't fix the multi-protocol cells). The word document is a draft of the explanation that would go with these tables (and which is needed anyway, as Issue 048 points out) 
 
I've stuck fairly closely to the existing style in terms of naming, but have applied the assumptions of several of the other open issues. One of the intents of the restructure is to define the inter-protocol interactions clearly (fixing 037). I have applied the editorial change suggested in 041 (protocol-breaking cells are shown as empty), the technical change from 041 (protocol-breaking cells don't specify state changes), the UnknownTransaction reply to an orphan Prepared (issue 039, 043). Issue 038 is fixed in passing.
 
My intention in drafting was that an existing implementation would not require changing, other than these points. (An implementation based strictly on a private interpretation of the state tables might, but I have attempted to capture what I think that private interpretation is actually doing).
 
There are some other sub-issues that arise from this clearer specification  - without clear definitions of the events and actions in the existing tables it is not possible in some cases to be sure if these are real differences (see Issue 048 - I don't agree with some of Alastair's proposed definitions).  One point that I have assumed is that a WS-AT coordinator will (or at least MAY) send Commit (or Rollback) to *all* of its participants at the same time (and not to durable first, volatile second). (There is no statement to the contrary, so I have argued from silence - if your application expects ordering, you better raise an issue)
 
I've not yet added the behaviour of a sub-coordinator, which requires a mapping between participant actions and node table events and vice versa. I've also missed out a rule about only one completion registration.
 
Obviously the detailed formatting changes (empty cells, * for unchanged state etc), the particular technical changes (which fault, expiry behaviour etc) are distinct from the main restructuring.
 
 
 
Peter
---------------------
Peter Furniss
consultant, erebor ltd
 
 
 
 
 
 

State_tables_explanation.doc

at_tables_mod1.xls



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]