[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 039 - WS-AT: Coordinator should not distinguishprotocol of orphaned participants
Understood. But this "something in the EPR" needs to be standardised, or we may have interoperability issues (I suppose we could bury it in ReferenceParameters!). Hence my vote for option b. Mark. Peter Furniss wrote: > In case it isn't clear where things are now: > > Option a) is what the spec says at present. There is no difference in > the Prepared message, but the state table says the coordinator has to > distinguish. Therefore there must be something in the coordinator's EPR > that allows the coordinator implementation to work out what sort of > participant it gave that EPR to in the RegisterResponse before the > coordinator crashed. > > Option b) would be a change, so that the coordinator table said "send > UnknownTransaction". > > Peter > > -----Original Message----- > From: Mark Little [mailto:mark.little@jboss.com] > Sent: 11 May 2006 12:27 > To: Peter Furniss > Cc: Ram Jeyaraman; ws-tx@lists.oasis-open.org > Subject: Re: [ws-tx] Issue 039 - WS-AT: Coordinator should not > distinguish protocol of orphaned participants > > So it's option b) again then :-) > > Mark. > > > Peter Furniss wrote: > >> Ram, >> It isn't a question of a more meaningful message, but of which side is >> > > >> required to distinguish what the now-broken relationship was: >> a) the side that now knows nothing of the relationship and therefore >> has to juggle its own addressing at implementation time so it can >> infer the answer >> b) the side that does know of the relationship and needs to behave >> differently Peter >> >> ---------------------------------------------------------------------- >> -- >> *From:* Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com] >> *Sent:* 11 May 2006 03:34 >> *To:* Peter Furniss; ws-tx@lists.oasis-open.org >> *Subject:* RE: [ws-tx] Issue 039 - WS-AT: Coordinator should not >> distinguish protocol of orphaned participants >> >> Peter, >> >> It is desirable to send a participant a more meaningful message. To >> that end, option (a) you have described below seems quite reasonable. >> >> ---------------------------------------------------------------------- >> -- >> >> *From:* Peter Furniss [mailto:peter.furniss@erebor.co.uk] >> *Sent:* Saturday, May 06, 2006 4:02 AM >> *To:* Ram Jeyaraman; ws-tx@lists.oasis-open.org >> *Subject:* RE: [ws-tx] Issue 039 - WS-AT: Coordinator should not >> distinguish protocol of orphaned participants >> >> But there is no need for a coordinator in None to distinguish. >> >> In any state other than None, the coordinator of course knows which >> protocol is in use, because it has an established relationship (and a >> state-referencing endpoint) from the Register. So considerations there >> > > >> (i.e. the other state transitions) are irrelevant to this matter. >> >> In state None, the coordinator has no such relationship. It doesn't >> even really have a state-referencing endpoint - there's just some >> catcher for incoming messages that target endpoints that don't exist >> (e.g. the despatcher triggers its else/default actions). It doesn't >> care. It isn't going to change state. It isn't going to do anything >> about the message except reply to it. >> >> The only requirement on our protocol is that the participant (which >> obviously does know what it registered for, and does care) is not >> mislead. And, as explained in the issue, a participant in Prepared >> that is told the coordinator is in state None does different things >> depending on whether it was durable or volatile. >> >> There are two solutions: >> >> a) we require that there be something in, associated with, enveloping >> or otherwise marking the Prepared message such that the coordinator >> can determine what kind of participant sent it, and send back >> different signals. We don't need to mandate a particular means, but >> there must be something on the wire that distinguishes a Prepared from >> > > >> volatile with Prepared from durable >> >> b) a coordinator in state None sends back a reply to Prepared from any >> > > >> kind of participant, the reply distinguishably telling the participant >> > > >> the coordinator is in None, and the participant interprets this >> appropriately dependent on what kind it is. >> >> Replying "UnknownTransaction", regardless of protocol, simplifies the >> protocol. Coordinator implementations don't need to do anything >> > special. > >> Peter >> >> ---------------------------------------------------------------------- >> -- >> >> *From:* Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com] >> *Sent:* 06 May 2006 03:07 >> *To:* ws-tx@lists.oasis-open.org >> *Subject:* RE: [ws-tx] Issue 039 - WS-AT: Coordinator should not >> distinguish protocol of orphaned participants >> >> This issue poses a valid question: How to handle the receipt of a >> 'Prepared' message while the coordinator state machine is in 'None' >> > state. > >> But in that question is the answer: The state transitions imply that >> an implementation should distinguish between volatile and durable >> participants; for example, as outlined in this issue description. That >> > > >> is, an implementation is expected to achieve this in an implementation >> > > >> specific way. >> >> Mandating a specific mechanism is unnecessary since this can be >> achieved via a suitable mechanism that works best for an >> implementation. Further, we certainly want implementations to >> distinguish between volatile and durable participants, so that >> messages from durable participants can be meaningfully handled. >> >> ---------------------------------------------------------------------- >> -- >> >> *From:* Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com] >> *Sent:* Tuesday, March 28, 2006 10:22 AM >> *To:* ws-tx@lists.oasis-open.org >> *Subject:* [ws-tx] Issue 039 - WS-AT: Coordinator should not >> distinguish protocol of orphaned participants >> >> This is identified as WS-TX issue 039. >> >> Please ensure follow-ups have a subject line starting "Issue 039 - >> WS-AT: Coordinator should not distinguish protocol of orphaned >> participants". >> >> ---------------------------------------------------------------------- >> -- >> >> *From:* Peter Furniss [mailto:peter.furniss@erebor.co.uk] >> *Sent:* Monday, March 27, 2006 1:27 PM >> *To:* ws-tx@lists.oasis-open.org >> *Subject:* [ws-tx] WS-AT: Coordinator should not distinguish protocol >> of orphaned participants >> >> Issue name -- WS-AT: Coordinator should not distinguish protocol of >> orphaned participants >> >> 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 Volatile 2PC >> >> Artifact: spec >> >> Draft: >> >> AT spec cd 1 >> >> Link to the document referenced: >> >> http://www.oasis-open.org/committees/download.php/17325/wstx-wsat-1.1- >> spec-cd-01.pdf >> >> Section and PDF line number: >> >> section 10, lines 503/505 tables rows Prepared, Relay, column None >> >> >> Issue type: >> >> Design >> >> >> Related issues: >> >> New issue: WS-AT: Invalid state inappropriate response to orphaned >> volatile participants >> >> Issue Description: >> >> The requirement that a coordinator with no current knowledge of a >> participant can determine which protocol it previously registered with >> > > >> from an incoming Prepared or Replay messages imposes unnecessary >> requirements on implementations. The desired functionality can be >> achieved with a common response to all such messages from "orphans", >> and letting the participant interpret that response. >> >> Since a returned fault does not show in the state tables, there is >> currently no behaviour specified for the volatile participant that >> sent the Replay or Prepared (this will become a separate issue if the >> main one is rejected, but it gets subsumed if this is fixed) >> >> Issue Details >> >> Background: >> The None state for WS-AT means that there is no record of the >> transaction - either because the transaction completed (rolledback or >> committed) or the coordinator crashed (and thus implicitly >> rolledback). Among correct implementations, Prepared and Replay >> messages received in the None state can only come from participants >> that were registered prior to the completion or crash, but did not >> receive a Commit or Rollback message. >> >> For a durable participant, this cannot happen if the transaction >> committed - the coordinator cannot forget the transaction until it has >> > > >> received Committed from the durable participant. Thus if the Prepared >> or Replay are received from a durable participant in the None state, >> it can be inferred with certainty that the transaction rolledback (by >> intent or crash). >> >> For volatile participants however, it is legitimate for the >> coordinator to delete its commit log record after receiving Committed >> from all durable participants, without waiting for any response from >> volatile participants. If there is a crash at this point (or just some >> > > >> lost messages), Prepared or Replay can be received from a volatile >> participant and find the coordinator in state "None". >> >> The issue: >> The specification currently requires that the coordinator distinguish >> between the two kinds of registration. This in turn requires that >> there is something about the Prepared or Replay message that allows >> the coordinator to determine the protocol of the forgotten >> registration (ipso facto, it has no specific, local information). >> Since there is nothing in the Prepared or Replay messages as such, >> this can only be something carried in or implied from the addressing >> for the coordinator. Although this can of course be done, and for some >> > > >> implementations may be entirely natural (e.g. if they have >> twinned-but-distinct multi-lateral coordinators for volatile and >> durable), for others it will be unnatural. >> >> There seems no reason for imposing this peculiarity (other perhaps >> than the unstated aesthetic that the coordinator has the driving seat >> in this protocol). If the coordinator gave the same response to >> Prepared/Replay from either protocol, it would be up to the >> participant to determine how it should treat this response. Since the >> participant certainly knows how it registered, there would be no >> ambiguity. >> >> (This issue has been distinguished from the question of using Invalid >> State in the volatile case - it would be even worse to use for >> InvalidState for the both protocols) >> >> There is currently no defined behaviour for the volatile participant >> that sends Replay or Prepared (since fault behaviour is not defined). >> >> Proposed resolution >> >> Define new message UnknownTransactionOutcome. >> >> Amend state table for Coordinator to send the new message when >> Prepared or Replay are received in state None. >> >> Amend state table for Participant with row for inbound >> "UnknownTransactionOutcome" >> this is invalid (shouldn't happen) in all states except >> PreparedSuccess >> >> in PreparedSuccess >> if participant is Durable action is Initiate Rollback and Forget, >> transition to Aborting >> >> if participant is Volatile, action is Forget, transition to new state >> UnknownOutcome >> >> UnknownOutcome state has transition to None on All Forgotten event. >> All other Inbound Events are ignored, without transition. >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]