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

["Ram Jeyaraman" <Ram.Jeyaraman@microsoft.com>]

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