[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]