Alastair,
> Why does reception of Committed during Preparing by Coordinator View
lead to state Aborting, when reception of Committed during Prepared
Success leads to "same state", i.e staying in Prepared Success?
The arrival of a Committed message from a participant who has not
been told to commit is a protocol violation. That is, the participant has acted
unilaterally. The decision to send a Commit or Abort to the participant may have
been taken (asynchronously), but it has not been enacted, meaning, a Commit or
Abort message has not been sent out (possibly log write is in progress). The enactment
of the commit decision (upon successful Write Done internal event) would
trigger the state transition from Prepared Success to Committing or Aborting
states.
Sending an Inconsistent Internal State fault (as opposed to Invalid
State) distinguishes this case because it is no longer possible to change the
outcome.
> If Committed might be the right answer, but it comes before the question
has been asked, why treat it as the wrong answer while preparing, but as
a potentially correct answer when prepared?
Yes, it is possible to optimize the behavior. But it is an implementation
choice.
From: Alastair Green
[mailto:alastair.green@choreology.com]
Sent: Tuesday, August 08, 2006 5:53 AM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] [Fwd: Issue 041: Seemingly arbitrary reactions to
protocol errors]
Fourth reposting.
-------- Original Message --------
Question:
Why does reception of Committed during Preparing by Coordinator View
lead to state Aborting, when reception of Committed during Prepared
Success leads to "same state", i.e staying in Prepared Success?
Turn the question around:
If Committed might be the right answer, but it comes before the question
has been asked, why treat it as the wrong answer while preparing, but as
a potentially correct answer when prepared?
Supplementary question:
Did the authors intend to accommodate races between the coordinator and
over-eager participants?
Alastair