[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
I disagree with the notion that formal definitions are not needed.
I find the resistance to defining terms odd. If a term has a clear and
well-defined meaning, then why not state it? One can brandish the
bogeyman of implementation restrictions, but the reality of that
"danger" needs to be demonstrated.Which, where, how?
It would be more productive and enlightening to debate what is wrong
with the proposed definitions in the resolution to this issue. As Peter
correctly says, by doing that we will verify the tables.
We will also uncover names that are completely counterintuitive.
Example: The PV internal event All Forgotten means: "Took a decision to
go read-only". Oh, but it also means "The word Forget appears somewhere
as a prior action: let's get ourselves to None". Clear? Obvious?
A lot less effort expended on achieving "no change", and a little more
effort put into getting a clearer, more precise spec would be good. This
is a combination of debugging and editorial improvement, and I think the
result will be a spec that better explains its purpose and design intent.
Alastair
Peter Furniss wrote:
> Please explain what "Commit Decision" means for a Participant.
>
> I don't believe a sensible definition is possible, whether or not you
> include implementation assumptions. The absence of definitions is hiding
> a bug.
>
> Also what is meant by
> "Record Outcome" (for c and p, volatile and durable)
> And
> "Write Done"
>
> By not including definitions, we are asserting the meaning is obvious,
> so it should be easy to devise strawmen. (if the strawmen turn out to
> always include implementation assumption, ok, we shouldn't have them)
>
> Peter
>
> -----Original Message-----
> From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
> Sent: 18 July 2006 19:56
> To: ws-tx@lists.oasis-open.org
> Subject: RE: [ws-tx] Issue 048 - WS-AT: Internal events and actions
> undefined
>
> Any other opinions on this issue?
>
> I suggest that we do not define internal events (details below).
>
> -----Original Message-----
> From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
> Sent: Thursday, July 13, 2006 8:12 AM
> To: Peter Furniss; Alastair Green
> Cc: ws-tx@lists.oasis-open.org
> Subject: RE: [ws-tx] Issue 048 - WS-AT: Internal events and actions
> undefined
>
> 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.]
>>
>>
>>
>>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]