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

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

I believe, the current labels for internal events, minimally describe
what they are.

Piling on any more semantic runs the risk of describing implementation
assumptions.

-----Original Message-----
From: Peter Furniss [mailto:peter.furniss@erebor.co.uk] 
Sent: Wednesday, July 12, 2006 3:07 PM
To: Ram Jeyaraman; Alastair Green
Cc: ws-tx@lists.oasis-open.org
Subject: RE: [ws-tx] Issue 048 - WS-AT: Internal events and actions
undefined

It is probably true that we should not *formally* define the internal
events - to do so would require the construction of a model of the
implementation, which would take some effort if we were to avoid
requiring unnecessary things of implementations (I think it could be
done, but would be some effort).

On the other hand, just to have two- and three-word labels that often
obscure and in some cases are downright misleading will make the
specification the subject of derision from those outside the committee.
To take perhaps the most extreme example, consider the "Commit Decision"
action in the Participant table - this is deemed valid in Preparing and
Committing, though it obviously means different things in the two cases.
Or Commit Decision, or the output action Record Outcome for the
coordinator view - if you think a little about what the defintion of
those would be, you run into the volatile:durable distinction, and the
definition becomes very complicated.

One could perhaps get away with this if the events were just labelled
"A", "B" etc (though you'ed still want to have two for Participant
"Commit Decision"), but as it is some of the names are just misleading.
Working out brief definitions, that need not over-specify
implementation, will force us to make sure they make sense. As it is, I
don't believe they all do (and the names risk exactly that
over-specification too) - and  I challenge those who don't want clarity
to prove the tables (and prove me wrong) by coming up with definitions
that do reflect what is intended (even if we don't include them).

Peter

-----Original Message-----
From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
Sent: 12 July 2006 20:16
To: Alastair Green
Cc: ws-tx@lists.oasis-open.org
Subject: RE: [ws-tx] Issue 048 - WS-AT: Internal events and actions
undefined

Alastair,

While it is true that the internal events have a direct influence on the
overall result, they are internal to an implementation, and hence, that
level of detail is not required for wire-level interoperability.
 
-----Original Message-----
From: Alastair Green [mailto:alastair.green@choreology.com]
Sent: Wednesday, July 12, 2006 8:52 AM
To: Ram Jeyaraman
Cc: ws-tx@lists.oasis-open.org
Subject: Re: [ws-tx] Issue 048 - WS-AT: Internal events and actions
undefined

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.]
>
>
>