Re: [ws-tx] Issue 039 - WS-AT: Coordinator should not distinguishprotocol of orphaned participants

[Mark Little <mark.little@jboss.com>]

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.
>