RE: [ws-tx] Interop scenario 4.1 and state tables

I have some comments inserted below.

From: Peter Furniss [mailto:peter.furniss@erebor.co.uk]
Sent: Monday, August 07, 2006 2:22 AM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] Interop scenario 4.1 and state tables

(sent earlier when ws-tx list was broken - i think it may now be working). Minor changes since first sending.

In interoperation tests, the following question arose:

In interop scenario AT 4.1, the following sequence occurs:

1. Initialization

1. IA sends an application message tns:EarlyReadonly request to PA

2. PA registers PS1 with CS for Volatile2PC protocol.

3. PA registers PS2 with CS for Durable2PC protocol

Message Exchange

4. PS1 sends Volatile2PC::ReadOnly to CS

5. PA sends application response message tns:Response to IA.

(I initiates Commit)

6. CS sends Durable2PC::Prepare to PS2

7. PS2 sends Durable2PC::Prepared to CS

8. CS sends Durable2PC::Commit to PS2

(CS Commits the transaction)

9. 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.

[Ram Jeyaraman] We should fix this. I think this is issue 61.

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.

[Ram Jeyaraman] The scenarios indicate that the steps 4 and 5 occur in a sequence. Is it possible to implement the scenarios such that there is no race between these two steps (4 and 5)?

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.

[Ram Jeyaraman] CS will be in Preparing state, since it has already emitted a Prepare. The ReadOnly (from step 4) will cause CS to forget the participant. Any subsequent response to Prepare sent forth by the participant would have no effect, since CS has forgotten the participant.

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

ws-tx message