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.

[PRF] yes, 61 would provide a defined state transition.

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)?

[PRF] steps 4 and 5 are effectively one-way messages to separate (but obviously related) endpoints. There is nothing a participant can do unilaterally to make sure that message 4 is received *and actioned* before 5. It can ensure it sends them in the right order, but if the coordinator decouples the acceptance (sending http 202) from the processing, they can get re-ordered internally - which is what happened. One could modify the implementation to ensure strict ordering on the processing by the internal working threads, but that would seem to be forcing the behaviour to fit an assumption that isn't really valid here.

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.

[PRF] The ReadOnly/Preparing cell is "Forget; Preparing". But "Forget" isn't necessarily immediate (or this would be "Forget;None"), so the state machine may still be there and get the Aborted delivered to it. A tighter definition of Forget might be that the state engine is immediately disconnected from the endpoint, but in fact that would be to make this transition to None as well (since an inaccessible state engine will mean the message if fielded by the general handler for None states)

Surely PS1 ought to respond with ReadOnly - but that means it must have changed state before or when sending the first ReadOnly.

[PRF] issue 61 proposal would transit participant to None, so the response would be Aborted.

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

[PRF] - solution for issue 61 includes defining transitions for intended legitimate behaviour, so is moving that way.

(note that the state diagrams don't help us here, because they don't deal with all the collision cases)

Peter

ws-tx message