[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
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] 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] 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]