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]