Re: [ws-tx] Issue 048 - WS-AT: Internal events and actions undefined

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

Ram,

The internal events cause state transitions without which the state 
tables do not work. Either they do have a clear meaning (in which case, 
why not write it down?), or they don't mean or do anything. Example: log 
write failure leads to transaction abortion. If an implementer chooses 
to ignore that rule, then the overall result (global state) of the 
completed transaction will be different from that expected. This is not 
what is normally meant by "illustrative".

Alastair.



Ram Jeyaraman wrote:
> 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.]
>
>
>