[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
+1 on UnknownTransactionOutcome Mark. Peter Furniss wrote: > 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]