RE: [ws-tx] Issue 052 - WS-AT: Replay message generates protocol errors

["Peter Furniss" <peter.furniss@erebor.co.uk>]

I think it is likely the state table is being misinterpreted. I'm not
sure by who :-)

If you treat the state as referring to just one participant, you either
get some very convoluted definitions of the internal events (c.f. issue
048 - but more convoluted that the ones proposed there) or you violate
atomicity.

Receiving a 'Prepared' message doesn't move the state to PreparedSuccess
- that's done by "Commit Decision", and until then 'Replay' would cause
an abort. You could define "Commit Decision" as meaning "receipt of ok
vote for just this one participant", and take the state for this
participant to PreparedSuccess. But the only way to leave
PreparedSuccess is from "WriteDone" or "WriteFailed". Since a 'Aborted'
from another participant should certainly cause this participant to be
rolled back, that 'Aborted' will have to trigger "WriteFailed", which is
not an obvious interpretation.


But I think this issue, with 053 (eliminate Replay) is more about
whether Replay need ever force an abort. We may be looking at a
carry-over from connection-centric protocols, where it made sense to
force an abort if the connection broke before commit-time. In those
worlds (more or less all transaction protocols that weren't using xml
and/or web-services, I think), receipt of a recovery message before the
connection was observed to break could only mean the connection break
was about to happen. But with WS-AT (especially because we have said all
messages go on the underlying request) there is no connection to be
monitored anyway. The coordinator hasn't noticed that participant was
out of communication for a while, and now the participant says it is
ready for the commit. Why *require* the coordinator to abort ?

Of course that's not to say the coordinator cannot *choose* to abort by
implementation option if replay is received (or any other circumstance
that leads the coordinator to suspect a failure somewhere). It can
always do that if it hasn't progressed too far - it would appear in the
tables as a User Rollback or Write Failed. 


Peter

-----Original Message-----
From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com] 
Sent: 06 May 2006 02:09
To: ws-tx@lists.oasis-open.org
Subject: RE: [ws-tx] Issue 052 - WS-AT: Replay message generates
protocol errors 

Section 10 (AT specification) states "These tables present the view of a
coordinator or participant with respect to a single partner".  Thus, the
coordinator states correspond to interactions with a single participant.

The receipt of a participant vote "PreparedSuccess" triggers the
coordinator state to "PreparedSuccess" with respect to that particular
participant, even though the coordinator may not have completed the
prepare phase for the rest of the participants.

Is it possible that the state table is likely being misinterpreted?

-----Original Message-----
From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
Sent: Thursday, April 06, 2006 10:50 AM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] Issue 052 - WS-AT: Replay message generates protocol
errors 

This is identified as WS-TX issue 052.

Please ensure follow-ups have a subject line starting "Issue 052 -
WS-AT: Replay message generates protocol errors ".

-----Original Message-----
From: Alastair Green [mailto:alastair.green@choreology.com]
Sent: Wednesday, April 05, 2006 5:07 PM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] New Issue: WS-AT: Replay message generates protocol
errors 

Issue name -- WS-AT: Replay message generates protocol errors

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:

Coordinator View State Table, after l. 503


Issue type:

Design


Related issues:

New issue: WS-AT: Eliminate Replay message. 
New issue: WS-AT: Is logging mandatory?


Issue Description:

Replay reactions defined in current CV state table will cause
unnecessary transaction aborts.
 

Issue Details:

The cells in row (Inbound Messages) Replay, columns (States) Active and 
Preparing read:

Active: Send Rollback --> Aborting
Preparing: Send Rollback --> Aborting

Replay message means: "play it again Sam", not "demolish the piano".

Case A. If the last thing they sent was Prepared, and it got through 
(we're Preparing and we've recorded their vote), and they've recovered, 
and they're waiting for a Commit or a Rollback, then we need to Ignore 
the Replay (just like if they send it when we've done our own 
housekeeping, and moved to Prepared Success).

Case B. If the message didn't get through, and we've processed User 
Commit then we could be in the Preparing state, but have no record of 
their vote. In that case we'd have to replay Prepare to indicate to 
them, send us your vote again.

Case C. If the last thing we received was Register, and we haven't 
processed User Commit, then we're still Active and they won't have 
logged. Replay won't happen on crash recovery (no log record to recover 
off), but it could be used to say to the coordinator "Are you still 
there? Should I crap out?" (i.e., because of impatience). We can't stop 
them using Replay in that fashion. Our only sensible response would have

to be: silence (we don't have a blank ack to a ping), i.e. to Ignore. 
There is no harm in them doing this, even though it is pointless. You 
could argue that this should be a N/A but that seems heavy-handed.


Proposed Resolution:

As the state tables do not differentiate between Preparing/no vote 
recorded and Preparing/vote recorded, it seems easiest to always resend 
Prepare in the Preparing state. Therefore:

Replace the current text in the cells in row (Inbound Messages) Replay, 
columns (States) Active and Preparing with:

Active: Ignore --> Active
Preparing: Resend Prepare --> Preparing