[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 052 - WS-AT: Replay message generates protocolerrors
Peter Furniss wrote: > 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. > We already agreed prior to the last f2f (in telecons) and at the last f2f (during the meeting) that the state table is not referring to just one participant. > 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 ? > Agreed. > 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. > Yes, I'd like to see this as an implementation specific choice. Mark. > > 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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]