[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-tx] Issue 048 - WS-AT: Internal events and actions undefined
Since internal events used in the specifications are illustrative, we probably do not need to formally define them. -----Original Message----- From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com] Sent: Thursday, April 06, 2006 10:47 AM To: ws-tx@lists.oasis-open.org Subject: [ws-tx] Issue 048 - WS-AT: Internal events and actions undefined This is identified as WS-TX issue 048. Please ensure follow-ups have a subject line starting "Issue 048 - WS-AT: Internal events and actions undefined". -----Original Message----- From: Alastair Green [mailto:alastair.green@choreology.com] Sent: Wednesday, April 05, 2006 4:33 PM To: ws-tx@lists.oasis-open.org Subject: [ws-tx] New Issue: WS-AT: Internal events and actions undefined Issue name -- WS-AT: Internal events and actions undefined 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, Participant View table, between ll. 510 and 511. Issue type: Editorial Related issues: New issue: WS-AT: Is logging mandatory? New issue: WS-AT: Comms Times Out internal event should be removed from state tables Issue 036: WS-AT: Coordinator state machine incomplete Issue Description: None of the user events are defined. Many of the less obvious state table actions are undefined. This issue attempts to carve out and resolve a specific sub-issue raised in less detail in issue 036. Issue Details: While reviewing the AT tables I wrote myself a rough glossary of events and actions, to make sure I understood the tables correctly. I think other readers would benefit from the same kind of guidance, so I've polished it up as a proposed addition to the spec. The internal events and actions should be defined to avoid misunderstanding, ambiguity and underspecification, and to achive this, it is much easier to define them separately for Coordinator View and Participant View. For example, "User commit" means "the application has decided to request the transaction be committed". "Commit decision" means: "The coordinator has determined that the votes of remaining participants are all in, and that commit-phase processing can commence; a log of this decision will now be made." To take another example: "Record vote" really means "no-op", whereas "Record Commit" (usually) means "attempt to write a log record". Or, again: "Record Outcome" means record coordinator wide commit decision in CV, but "Record Commit" means "record prepared decision" in PV. Or, further: "User Commit" is an internal event that could be stimulated by Completion protocol Commit message being received, and the same, mutatis mutandis, for "User Rollback". An allied issue is the use of the term "Return" in state table actions meaning: send a "message", signal to the application that requested commit or rollback. This is not defined. All of these things are deducible, but it would be clearer and more precise to spell them out. There may be a case for renaming some of these events for greater clarity, but I have concentrated on writing down the meaning as I understand it. Proposed Resolution: a) Move ll. 505 - 508 ("Notes") to follow line 503 (come before CV state table). b) Delete ll. 509 - 510. (Note on Forget, re-covered in proposed new text below). c) Add before the CV state table (after line 503, and after moved text from existing ll. 505 -508) text as follows: The following internal events and actions used in the Coordinator View table below have the following meanings: User Commit An application has signalled to the coordinator that it would like the coordinator to attempt to commit the transaction, i.e. to begin to process first the Volatile stage and then the Durable stage of the first, prepare phase of the 2PC protocol (See Section 4.3 "Two-Phase Commit Protocol"). Delivery to the coordinator of the Completion protocol message Commit will cause this event. User Rollback An application has signalled to the coordinator that it would like the coordinator to rollback the transaction. Delivery to the coordinator of the Completion protocol message Rollback will cause this event. Return (action, as in Return Committed, Return Aborted) The coordinator should signal the application that requested commit or rollback with the outcome of the transaction if already known. Expires Times Out The CoordinatorContext Expiry interval has elapsed in accordance with the rules stated in Section 3, "Atomic Transaction Context". Comms Times Out A transient message delivery failure has occurred, and message redelivery may be attempted. [I think this should go, subject of another issue.] Record Vote (action) The coordinator stores the fact that the participant has sent Prepared. The transition to state Prepared is a sufficient record. The record need never be made persistently (need not be logged, even if the execution is crash recoverable). Commit Decision The coordinator has determined that all participants which did not send ReadOnly in response to Prepare have sent Prepared, and that the transaction should therefore be committed, starting with the attempt to record the commit decision. Record Outcome (action) [NB that CV records "Outcome" and PV records "Commit"] Following the event Commit Decision the coordinator must attempt to record the commit decision (which will involve logging the decision if the execution is crash recoverable). Write Done The action Record Outcome succeeded: the commit decision was recorded (in a crash recoverable execution, a persistent record was successfully written). Write Failed The action Record Outcome failed. This will only occur during a crash recoverable execution, if a persistent record of the commit decision could not be made. Forget Ignore the participant hereafter: i.e. do not involve it in the commit decision, nor in the second commit phase of the 2PC protocol. This ensues on receipt of a ReadOnly vote from the participant. All Forgotten The coordinator has detected that all of its registered participants have voted ReadOnly. [This feels ugly. The state transitions consequent on this affect the whole transaction, and not just the participant concerned, but that's another class of problem. -- AG] d) Add the following text just before the PV state table (after line 510) as follows: The following internal events and actions used in the Participant View table below have the following meanings: Gather vote decision (action) Obtain from the participant application (e.g. a resource manager) a decision as to its desired involvement in the transaction. The vote decision is the participant's response to the Coordinator's Prepare message, and can be one of Prepared, ReadOnly or Aborted. Expires Times Out The CoordinatorContext Expiry interval has elapsed in accordance with the rules stated in Section 3, "Atomic Transaction Context". Comms Times Out A transient message delivery failure has occurred, and message redelivery may be attempted. [I think this should go, subject of another issue.] Commit Decision The participant application has decided to vote Prepared, and the participant must now record that decision prior to sending Prepared to the coordinator. Record Commit (action) Following the event Commit Decision the participant must attempt to record the decision to vote Prepared, (indicating that it wishes the transaction as a whole to commit). In a crash recoverable execution the record must be persistent. Write Done The action Record Commit succeeded: a record of the prepared decision was successfully made (in a crash recoverable execution, a persistent record was successfully written). Write Failed The action Record Commit failed. This will only occur during a crash recoverable execution, if a persistent record of the commit decision could not be made. Rollback decision The participant application has decided to vote Aborted, and the participant must now send Aborted to the coordinator. Forget (action) The participant has done its job with respect to the transaction, and need not remember its relationship to the coordinator nor what its last state prior to forgetting was. Forgetting involvement may impede the ability of the transaction to survive communications failures, but will never prejudice the consistency of transaction outcome. All Forgotten The participant application has decided to vote ReadOnly, so the participant must now send ReadOnly to the coordinator, and can then forget its involvement in the transaction. [Can we please rename this one ReadOnly decision in this table? There's no "All" about it.]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]