-
- IA
sends an application message tns:EarlyReadonly request to PA
- PA
registers PS1 with CS for Volatile2PC protocol.
- PA
registers PS2 with CS for Durable2PC protocol
- PS1
sends Volatile2PC::ReadOnly to CS
- PA
sends application response message tns:Response to IA.
(I
initiates Commit)
- CS
sends Durable2PC::Prepare to PS2
- PS2
sends Durable2PC::Prepared to CS
- CS
sends Durable2PC::Commit to PS2
(CS
Commits the transaction)
- PS2
sends Durable2PC::Committed to CS
Before performing 4, PS1 will
have been in state Active. There is no state table defined action for sending
ReadOnly from Active, nor any defined transition that would get the Participant
view to a state where it could send ReadOnly. Consequently, there is definition
of what state the participant is now in.
This showed up in the
interoperation when (probably by chance - it doesn't seem to
have repeated), the ReadOnly message was delivered *after* the application
response from 5. Consequently, "I" initiated commit before the ReadOnly arrived
and sent Prepare to PS1.
What should happen next ?
Should PS1 respond to the Prepare with Prepared ? If CS is still in
Active (which is what the state table says) then it throw InvalidState and
transit to Aborting when the Prepared arrives. If CS has now in None (for
this state engine only) it reply UnknownTransaction (since PS1 was a volatile
participant - had it been durable (which could do the same thing ) Rollback
would be sent.
Surely PS1 ought to respond
with ReadOnly - but that means it must have changed state before or when sending
the first ReadOnly.
(while looking for something else, I found my copy
of the agreed notes from the first day of the jan 2005 interop, which
raised the same question - what state is a participant in after sending
ReadOnly, and how should it respond to a received
Prepare.)
The underlying problem is
(Peter back on his hobby horse :-) the interpretation of the state tables that
messages can be sent/states transitioned that do not show on the state table.
This leaves the behaviour in this instance undefined, with surprise results that
show up sometimes in interoperation (i.e. this scenario is not fully
deterministic). If the interpretation of the state tables were strict,
then the scenario would be illegal - which is clearly wrong. The fix for this is
to include *all* the legitimate behaviour in the state tables - the scenarios
give a good basis for this: we should check that all the events required in the
scenarios reference cells in the tables.
(note that the state diagrams
don't help us here, because they don't deal with all the collision
cases)
Peter