[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
Just to reiterate something I said in the first response to Alastair's email "to the TC" earlier in the week: I don't think it is desirable to abort transactions in situation b) below. It's interesting to note that it is "only" the state table that indicates rollback will occur in that situation: all other text in the specification is silent (and in fact tends to push the reader in the opposite direction of the state table). Mark. Peter Furniss wrote: > The question as I see it is that the "semantics of Replay", which Mark > said he wanted to leverage in an earlier message, seem to be only that > it sabotages viable transactions in some circumstances (i.e. if received > before the coordinator logs). The only other semantics, as > Alastair is raising, seem to relate to connection-oriented and rpc > worlds that WS-AT has left behind. > > > So, > a) are there other "semantics of Replay" that are relevant to > the send-all-messages-on-outbound-connections pattern of WS-AT ? > > b) why is it desirable to abort transactions when all the > parties are able to commit and have informed the coordinator that they > are able to commit ? > > > > Peter > > -----Original Message----- > From: Mark Little [mailto:mark.little@jboss.com] > Sent: 12 May 2006 11:09 > To: Alastair Green > Cc: Peter Furniss; Ram Jeyaraman; ws-tx@lists.oasis-open.org > Subject: Re: [ws-tx] Issue 052 - WS-AT: Replay message generates > protocol errors > > > > Alastair Green wrote: > >> I'm sorry, but I don't get it. >> >> 1. Replay is never sent from the Coordinator to the Participant. >> > > I never said that, did I? > >> 2. If the Coordinator never receives Prepared, it resends Prepare. If >> it never gets Committed back, it resends Commit (your scenario). In >> each case it does so as often as it wants until it gets the *ed back. >> > > Sure. But that's top-down (coordinator driven recovery). I thought what > we were discussing was bottom-up (participant driven recovery). Can you > confirm that is your reading of the original issue too? > > >> 3. If the Participant fails and recovers, it knows that it may not >> have sent Prepared (it could fail between the log write and the >> message send), and must communicate the semantic "prepared". A message >> > > >> exists that carries exactly that semantic: Prepared. >> > > Or, it could send Replay ;-)? > > >> If the Participant tries to send Prepared (before or after crash >> recovery) and the message send fails to its knowledge (one >> interpretation of comms time out), it resends Prepared. >> > > Sure. No argument there: if it knows the Prepared failed to be > delivered, then it can obviously resend for an implementation > (potentially infinite) time. It could then periodically keep retrying. > Or, it could send Replay later. > > >> If the Participant never receives Commit or Rollback (another >> interpretation of comms time out), it again resends Prepared. >> > > Or Replay. > > >> In other words, the Participant sends and resends Prepared until it >> gets Commit or Rollback, across all failures and for all time. >> >> 4. The OTS replay_completion is not a precedent. OTS uses RPCs, not >> one-way messages. This makes retry behaviour more difficult to model. >> But if we strip that aside, we see that OTS does exactly the opposite >> of AT: it does not tolerate communications failure if the prepared >> semantic fails to get through, and it does not cause premature abort >> after a recoverable failure in the prepared state. In my view, both >> OTS and AT are wrong: *there is no reason to treat comms failure and >> crash recovery differently, either in mechanism of retrying or in >> effect on transaction outcome.* >> >> In OTS we say Vote vote = resource.prepare(), and the Vote enumeration >> > > >> tells us whether it's prepared, readonly or rollback. The operation is >> > > >> not idempotent -- a communications failure that prevents the vote >> returning will cause transaction abort. I think this is wrong and >> arbitrary, i.e it is a bad precedent and should not be copied. >> Correctly, AT does not copy this feature, and tolerates this failure >> (comms time out = resend Prepared). >> > > I think you're definitely misinterpreting my reference to > replay_completion: I'm talking only about the bottom-up recovery > scenario, which is exactly the same scenario this issue describes. > >> If the participant fails in OTS then it can't tell when it failed (did >> > > >> it ever return from the prepare operation, i.e. send back the Vote?) >> So, it has to send a message to say: "I am prepared" >> (replay_completion), and it will receive a status. It may also get a >> replay of commit or rollback, as these operations can be duplicated >> (they are idempotent). >> >> replay_completion is defined as being "a hint to the coordinator" that >> > > >> the prepared participant has never received commit or rollback. As a >> hint it cannot affect the state or the behaviour of the coordinator, >> other than to stimulate a replay of commit or rollback, speeding >> things up. Its semantic is: "I am prepared". (The additional semantic >> "And once I failed" is irrelevant.). Correctly, in OTS replaying the >> prepared semantic never causes transaction abort, as it wrongly can in >> > AT. > > I think you're mixing issues, which can only lead to confusion. Let's > keep this strictly at the issue in hand. It'll make it easier for > everyone else to follow. > >> The only reason for the existence of replay_completion as a distinct >> operation is because you can't return the response/return value of an >> RPC twice. >> >> If OTS had modelled this using one ways, it would have ended up with >> two interfaces (simplified, and forgetting my IDL syntax, and changing >> > > >> the real names to save looking them up): >> >> interface coordinator >> { >> void vote (in Vote); // Vote is an enum: Commit = Prepared, >> Readonly, Rollback >> } >> >> interface resource >> { >> void prepare(); >> void commit(); >> void rollback(); >> } >> >> Our failure scenario would then logically be: >> >> C invokes resource.prepare() >> P invokes coordinator.vote (Vote.Commit) >> P fails >> P invokes coordinator.vote (Vote.Commit) >> >> In AT this appears as >> >> C sends Prepare >> P sends Prepared >> P fails >> P resends Prepared >> >> The separate message replay_completion is an artefact of RPC, not of >> the requirements of the transaction protocol. >> >> The correct behaviour for AT is to resend Prepared in the face of >> comms failures, and after crash recovery. >> > > I disagree. The correct behaviour is to send Replay. > > Mark. > > >> Alastair >> >> Mark Little wrote: >> >>> Alastair Green wrote: >>> >>>> Hi Mark, >>>> >>>> Just one point: >>>> >>>> Mark Little wrote: >>>> >>>>> Since it crashed in Prepared Success state we should be able to >>>>> assume that the participant obeyed the rules and made its decision >>>>> to be able to commit durable. Hence, this Replay message should be >>>>> interpreted as a), though the semantic of "have recovered" >>>>> shouldn't exclude the fact that the failure may have been in the >>>>> network and not the participant service itself (for instance). >>>>> >>>>> >>>> One might think so, but in fact when the Participant experiences a >>>> comms time out it Resends Prepared (PV state table). >>>> >>>> Which begs the question: if that works for comm failures, why do we >>>> do something different for process failures which are recovered? >>>> >>> Different type of failure. I interpret the resend of Prepared on >>> comms failure to be in the case where the sender (the participant) >>> knows that the original Prepared wasn't delivered. My original >>> statement above referring to comms failures is more: there was a >>> network partition after Prepared was successfully delivered and this >>> partition has been healed. In the meantime, the coordinator >>> committed, couldn't contact the participant because of the network >>> partition and so must go into some form of recovery mode. From the >>> coordinator's perspective, there is no way for it to distinguish >>> between a network partition and the failure of the machine on which >>> the participant resides. From the participants perspective, there is >>> a difference, though the resolution is the same: it initiates a >>> Replay message. >>> >>> I just wanted to make sure our definition of failure didn't preclude >>> partitions. >>> >>>> The implication of the two events for the Coordinator, as you point >>>> out, should be identical (we are ensuring that the Prepared Success >>>> state is communicated to the Coordinator). >>>> >>> But these are different scenarios. As a slight (related) aside: the >>> OTS works fine with replay_completion on the RecoveryCoordinator, so >>> there is precedent for Replay. >>> >>> Mark. >>> >>> >>>> Alastair >>>> >>>> Alastair >>>> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]