[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: New Issue: WS-AT: Clarify late registration of participants in statetables
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/wstx-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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]