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