Issue 051 - WS-AT: Clarify late registration of participants in state tables

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

This is identified as WS-TX issue 051.

Please ensure follow-ups have a subject line starting "Issue 051 -
WS-AT: Clarify late registration of participants in state tables".

-----Original Message-----
From: Alastair Green [mailto:alastair.green@choreology.com] 
Sent: Wednesday, April 05, 2006 4:39 PM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] New Issue: WS-AT: Clarify late registration of
participants in state tables

Issue name -- WS-AT: Clarify late registration of participants in state 
tables

PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL 
THE ISSUE IS ASSIGNED A NUMBER.

The issues coordinators will notify the list when that has occurred.

Target document and draft:

Protocol:  WS-AT

Artifact:  spec

Draft:

WS-AT CD 0.1 uploaded

Link to the document referenced:

http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17325/ws
tx-wsat-1.1-spec-cd-01.pdf

Section and PDF line number:

Section 10, "State Tables", Coordinator View table, between ll. 503 and
504


Issue type:

Design


Related issues:

Issue 037 - WS-AT: Register/Preparing in coordinator state table
problematic


Issue Description:

Late registration of 2PC participants not correctly stated in CV state 
table.


Issue Details:

WS-AT Coordinator View state table, row (Inbound Event) Register, column

(State) Preparing, reads as follows:

Durable: Invalid State --> Aborting
Volatile: Send RegisterResponse --> Active

The transaction moves into the Preparing state as a result of a User 
Commit internal event, aka an application instruction to the coordinator

to initiate 2PC processsing.

For 2PC to work correctly it is necessary to freeze the pool of voters 
before the polls close. In theory this need not happen till the very 
last vote of the current pool has been received (the list can be 
extended while being processed). However, WS-AT in common with other 
atomic TMs and protocols (and with other types of election) chooses to 
simplify by freezing the pool when the polls open, i.e. when the 
application chooses to request commitment, at the beginning of the 
prepare (voting) phase. The argument behind this is that the terminating

(demarcating) application must have figured out (by some application 
protocol) that all the expected participating services are involved 
(usually termed checking), otherwise it wouldn't have requested
commitment.

With an atomic-only commitment protocol like AT this is reasonable. We 
should therefore never see an unexpected late registration of a durable 
participant, because the application should not have requested commit if

all services are not yet involved. This is the current situation for 
late durable registrations.

However, by this logic we should also expect that a volatile 2PC 
participant should never be registered late (unknown to the terminating 
application), once prepare phase processing has commenced. The vote of a

volatile participant is good enough to veto the transaction: why should 
the number of volatile participants be considered any less relevant than

the number of durable participants?

There seems no reason to differentiate the reaction of the coordinator 
to late registration of Volatile and Durable participants.


Proposed Resolution:

Amend WS-AT Coordinator View state table, row (Inbound Event) Register, 
column (State) Preparing, to read as follows:

Invalid State --> Aborting