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