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