[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-tx] Issue 056 - WS-AT: User Commit and User Rollback row of CV state table contradicts resolution of 010
At the Dublin F2F, we relegated this issue to dealing with duplicates. My earlier comments about duplicates is paraphrased below: "On the issue of duplicates: A nervous client may send a jittery sequence of "Commit, Commit, Rollback, Commit, Rollback, ..." message sequences; Or network retransmissions, as you point out, may result in "Commit, Commit, Commit, ..." or "Rollback, Rollback, Rollback, ..." sequences, or worse still, a malicious DOS attack may spew forth an unending sequence of "Rollback" and "Commit" messages! Clearly, the first message to arrive at the coordinator wins; consequently, the coordinator sets the 2PC/Rollback freight train in motion which never stops for a reason, except if it crashes on to an obstacle. More importantly, the coordinator state immediately moves away from an "Active" state to either "Preparing" or "Aborting", upon reacting to the first successful "Commit" or "Rollback" message. Any subsequent "Commit" or "Rollback" message that arrives at the coordinator has lost the chance to influence the outcome, since the coordinator has already moved on to "Preparing" or "Aborting" state upon the receipt of the first successful "Commit" or "Rollback" message. It is unsafe for an implementation to react to such potentially malevolent duplicate messages. Handling of duplicates can be best left to an implementation to deal with, and is probably not crucial for interoperability." As a resolution to this issue, I suggest the following: Rename the 2PC internal events "UserCommit/UserRollback" to "CommitRequested/RollbackRequested" to remove any confusion about the internal event and its relationship to the Completion protocol. -----Original Message----- From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com] Sent: Thursday, April 06, 2006 10:55 AM To: ws-tx@lists.oasis-open.org Subject: [ws-tx] Issue 056 - WS-AT: User Commit and User Rollback row of CV state table contradicts resolution of 010 This is identified as WS-TX issue 056. Please ensure follow-ups have a subject line starting "Issue 056 - WS-AT: User Commit and User Rollback row of CV state table contradicts resolution of 010". -----Original Message----- From: Alastair Green [mailto:alastair.green@choreology.com] Sent: Wednesday, April 05, 2006 5:16 PM To: ws-tx@lists.oasis-open.org Subject: [ws-tx] New Issue: WS-AT: User Commit and User Rollback row of CV state table contradicts resolution of 010 Issue name -- WS-AT: User Commit and User Rollback row of CV state table contradicts resolution of 010 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 10, "State Tables", Coordinator View table, between ll. 503 and 504 Issue type: Design Related issues: New Issue: WS-AT: User Commit and User Rollback should not return Aborted in None state Issue Description: Issue 010 proposed that replays of Completion protocol messages should be permitted, to allow initiators to discover state of transaction after initial termination request had been made. This was rejected almost unanimously. However, state tables permit replay. Issue Details: WS-AT Coordinator View state table, row (Internal Events) User Commit reads as follows: None: Return Aborted --> None Active: Send Prepare --> Preparing Preparing: Ignore --> Preparing Prepared: N/A Prepared Success: Ignore --> Prepared Success Committing: Return Committed --> Committing Aborting: Return Aborted --> Aborted Similar things happen with row User Rollback. Reception of User Commit engendered by Completion protocol Commit message may occur twice as a result of impatience, lost messages, transport bounce. State table handles this happily, replaying known outcomes (e.g if event arises when Aborting, Commit message will be responded to with Committed, even though message has already been sent on event Write Done. I like that, but the TC doesn't, by 16 to 1. Note that this issue is very tightly related to "WS-AT: User Commit and User Rollback should not return Aborted in None state". If all become forgotten (every participant goes aborted or committed) then the state flips to None. Speed at which that happens cannot be dictated (forgetting is a non-critical path activity, that may be deferred to some form of garbage collection or deferred for ever in a given implementation). Replays are therefore always possible in principle. Proposed Resolution: EITHER: Make text of completion protocol, definition of notification types etc conform with state table and recognize that duplicate Completion protocol Commits and Rollbacks cannot easily or sensibly be stopped (See Register/RegisterResponse discussion). OR: Ban duplicate responses in the state tables by faulting duplicate events.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]