[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 distinguish protocol of orphaned participants
Peter, I am sure you wouldn’t disagree: A
superior coordinator holds a responsibility to provide correct information about
the outcome. Stating “I don’t know” and letting the
subordinate make a unilateral conclusion about the outcome is not a desirable situation.
This gives room for varied interpretations of “I don’t know”,
which is not desirable. As transaction middleware providers we should attempt
to provide the best information possible, and it is critical that we build that
assumption into the protocol. For durable participants, I strongly support
Option A, you had proposed earlier. In the case of volatile participants, I
agree that a more meaningful fault, such as “UnknownTransaction” or
perhaps “InDoubt”, is better than “InvalidState”. Thank you. From: Peter Furniss
[mailto:peter.furniss@erebor.co.uk] 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: 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] 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: 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: 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] 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: Section and PDF line number: section 10, lines 503/505 tables rows Prepared, Relay,
column None
Design
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: 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: 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 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" |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]