[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/atodds with state table
Ian, I would agree with this terse wording if you would agree to change "it has not been prepared" to "it has not already decided to prepare". The attempt to write a confirm or prepare log is the event that stops the clock. If the timer goes ping and the log write is in progress, then we may start pursuing two simultaneous, contradictory paths through the state table. Note that the use of "2PC participant" was deliberately intended to exclude use of Expires in the Completion Protocol. I know you have retained this wording -- I just want to point this out in case there is any debate about that aspect. Alastair Ian Robinson wrote: > 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]