New Issue: WS-AT: Definition of expiry inadequate/at odds with statetable

[Alastair Green <alastair.green@choreology.com>]

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/wstx-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."