[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 049 - WS-AT: Definition of expiry inadequate/at odds withstate table
Section 3 of AT currently states:
"A coordination context may have an Expires attribute. This attribute
specifies the period, measured from the point in time at which the
context was first received, after which a transaction may be
terminated
solely due to its length of operation. From that point forward, the
transaction manager may elect to unilaterally roll back the
transaction,
so long as it has not transmitted a Commit or Prepared
notification."
This issue observes that the term "transaction manager" is imprecise, as is
the definition of the point of no return. I believe it would be useful and
sufficient to modify this text as follows:
"A coordination context may have an Expires <ir>element</ir>. This
<ir>element</ir>
specifies the period, measured from the point in time at which the
context was first <ir>created or received</ir>, after which a
transaction may be terminated
solely due to its length of operation. From that point forward, the
<ir>coordinator</ir> may elect to unilaterally roll back the
transaction,
so long as it has not <ir>made a commit decision. Similarly a 2PC
participant may elect to abort its work in the transaction so long as it
has not been prepared.</ir>."
Regards,
Ian Robinson
STSM, WebSphere Transactions Architect
IBM Hursley Lab, UK
"Ram Jeyaraman"
<Ram.Jeyaraman@mi
crosoft.com> To
<ws-tx@lists.oasis-open.org>
06/04/2006 18:47 cc
Subject
[ws-tx] Issue 049 - WS-AT:
Definition of expiry inadequate/at
odds with state table
This is identified as WS-TX issue 049.
Please ensure follow-ups have a subject line starting "Issue 049 -
WS-AT: Definition of expiry inadequate/at odds with state table".
-----Original Message-----
From: Alastair Green [mailto:alastair.green@choreology.com]
Sent: Wednesday, April 05, 2006 4:35 PM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] New Issue: WS-AT: Definition of expiry inadequate/at
odds with state table
Issue name -- WS-AT: Definition of expiry inadequate/at odds with state
table
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 3, "Atomic Transaction Context", ll. 120-123, as amended by
resolution of issue 023
Issue type:
Design / Editorial
Related issues:
Issue 023: Definition of expiry unclear
Issue Description:
Resolution of issue 023 blurs meaning of expiry for the coordinator and
participant. Point of no return misdefined (does not accord with the
state table). Fact that this attribute has no real meaning for
completion protocol is not stated.
Issue Details:
The new text agreed in resolution of 023 at the March 2006 F2F reads:
"A coordination context may have an Expires attribute. This attribute
specifies the period, measured from the point in time at which the
context was first received, after which a transaction may be terminated
solely due to its length of operation. From that point forward, the
transaction manager may elect to unilaterally roll back the transaction,
so long as it has not transmitted a Commit or Prepared notification."
But:
1) the transaction manager (better, the coordinator of the transaction)
does not receive the context, it generates it. In other words, the
transaction manager will start counting down to abortion of the
transaction at some point no later than the time it first emits a
context.
2) The entity that does receive the context is any registering service
that chooses to hook a 2PC participant into the transaction. Such a
recipient must never set a local expiry deadline for its registered
participants which is earlier than the absolute time of receipt of the
application message containing the context, plus the expiry. (Unless it
has some way of deducing network latency.) The existence of such an
actor is not made clear.
3) The definition of the "point of no return" is wrong (both for the
coordinator and the participant). The point of no return, as per the
state tables, is not the point of emission of the message, but the point
of deciding to attempt a log write.
4) The expiry interval is effectively meaningless for the Completion
protocol. Having been set (in the first place) by the initiator of the
transaction, it can reasonably be assumed that the terminator will be
directly aware of the interval concerned. In any event, what does it
mean for a completion participant to "time out"? Its only effect could
be to redeliver a rollback, which would be both duplicative and complex
to specify.
The expiry must be defined twice: in its effect on the coordinator, and
in its effect on registered participants. The definition of its meaning
should be restricted to 2PC participants.
The definition of the point of no return should be changed. Strictly
speaking it could be omitted altogether: the internal event of decision
to go prepared or to commit creates a state transition which precludes a
subsquent rollback decision being attempted). However, that seems
excessively opaque. Preferable to cross-refer the states.
Proposed Resolution:
Change the quoted section to read:
"A coordination context may have an Expires attribute. This attribute
specifies the period, measured from the point in time at which the
context was first published in a CreateCoordinationContextResponse
message, before whose passage a transaction will not be terminated by
the coordinator solely due to its length of operation. After that period
has elapsed, the coordinator may elect to unilaterally roll back the
transaction, so long as it has not yet made a decision to record commit
(i.e. entered the state PreparedSuccess). This attribute can be used by
any recipient of a coordination context which registers a 2PC
participant to calculate the point in time at which the participant can
safely decide to rollback because of delay in receiving a Prepare
message. A 2PC participant which has not yet decided to record prepare
(i.e. entered the state Prepared) may rollback after the Expires
interval has elapsed since the point at which the registrar of that
participant received the coordination context message."
If you want to avoid duplication of the state table, this could be
abbreviated to:
"A coordination context may have an Expires attribute. This attribute
specifies the period, measured from the point in time at which the
context was first published in a CreateCoordinationContextResponse
message, before whose passage a transaction will not be terminated by
the coordinator solely due to its length of operation. After that period
has elapsed, the coordinator may elect to unilaterally attempt to roll
back the transaction. This attribute can be used by any recipient of a
coordination context which registers a 2PC participant to calculate the
point in time at which the participant can safely decide to rollback
because of delay in receiving a Prepare message. A 2PC participant may
attempt to rollback after the Expires interval has elapsed since the
point at which the registrar of that participant received the
coordination context message."
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]