Re: [ws-tx] RE: State table intent (was RE: [ws-tx] Issue 036 - WS-AT:Coordinator state machine incomplete)

[Alastair Green <alastair.green@choreology.com>]

I don't want to underspecify the "internal" workings.

I think the use of "external"-"local/internal" in this discussion is inexact. The abstract behaviours are location transparent. What does "local system" mean? Is a log server executing on a separate host "local"? Is a database server operating on a separate host "local"?

Sending a protocol message is not the only "external" behaviour -- it is the only behaviour that is visible to the Coordinator if you are a Participant, and to the P if you are a C. The state machines have several interlocutors (logical entities which converse with the state machine), and they see and must see signals that are emitted by the state machines, and they must send signals to the state machines.

They are:

For the Coordinator View, the overall coordinator (Peter's B-coordinator) which tells the CV a) when to initiate 2PC, and b) what the final outcome is (if it cannot be deduced locally), i.e. if abort results from a Aborted to another CV, or if Commit is agreed by all CVs.

For the Participant View, the recording or logging entity, and the application or resource entity.

There are five roles at work in these state tables. The three that are hidden and undefined should be allowed to come out of the closet, so we can properly define who is doing what.

I don't see why this is a big deal -- we recognize them in fact (because we describe the signals to and from them in the "Internal Events"), but we don't name or describe them. That is underspecification.

I re-attach a Word diagram I posted previously that illustrates this for the Participant end.

Alastair

Peter Furniss wrote:

I don't want to overspecify the internal workings either, but sending a
protocol message is obviously external behaviour - in fact it's the only
thing that is.

It is obviously wrong for a participant to do something like:

	...
	send Prepared
	(no other protocol events)
	send Committed

Or indeed
	...
	send Prepared
	send Aborted
	send Prepared
	send Committed
	send Prepared

If you don't make the prohibitions I proposed (no state change, no
sending except as allowed), I don't see how you forbid those behaviours.
Without those rules, the implementation can claim it internally switched
from PreparedSuccess to Committing and back again.

A critical part of the text I proposed was that the states (and internal
events) are abstract - from an interoperable perspective, the only way
the outsider knows that the implementation considered itself to be
PreparedSuccess was because it sent Prepared. But because it did send
Prepared, then the outsider knows it was in PreparedSuccess and (by my
rule) it can't go to Committing until and unless it receives Commit.
What the implementation does to get itself into the Prepared state is
its problem.


You can take an alternative path, and define the internal events MORE
concretely - which is what OTS does for example. This may be more
natural, and easier to follow, but avoiding over-specification can make
it wordy. 


Yet another path is to drop this level of specification altogether -
which is roughly what the TIP rfc did - and assume its all well-known
transactionality. I'm not quite so sure its really as well agreed as
people might think - some of the discussions in Dublin hinged on edge
cases where just assuming all implementations will do the same thing
would produce implementations which "interoperated" to exchange the
right protocol messages, but actually failed to deliver atomic behaviour
of the work if spread across heterogeneous implementations.

Peter


-----Original Message-----
From: Ian Robinson [mailto:ian_robinson@uk.ibm.com] 
Sent: 14 June 2006 13:57
To: Newcomer, Eric; Peter Furniss
Cc: ws-tx@lists.oasis-open.org
Subject: RE: [ws-tx] RE: State table intent (was RE: [ws-tx] Issue 036 -
WS-AT: Coordinator state machine incomplete)

Eric, I agree.

We do not want to suggest that the state tables govern all aspect of the
internal behaviour of an implementation so perhaps we can improve things
a little and clarify what the scope of "Internal Events" actually means.
As discussed previously, the main body of the table describes
action/transition in the event that a protocol message is received by a
protocol endpoint; the "Internal Events" are provided to illustrate
state transitions and protocol message generation that occurs as a
result of something other than receipt of a protocol message.
The spec currently states "Internal events are those that are created
either within a TM itself, or on its local system."

Perhaps the spec would be clearer if we stated instead:
The "Internal events" shown are those events, created either within a TM
itself or on its local system, that cause state changes and/or trigger
the sending of a protocol message.

Beyond this, Section 10 already clearly states: "These tables present
the view of a coordinator or participant with respect to a single
partner.  A coordinator with multiple participants can be understood as
a collection of independent coordinator state machines."

Peter has suggested a modification to this text that includes the phrase
that Eric commented on below. I agree with Eric's comment. I suggest we
modify the first paragraph of WS-AT section 10 basde on a part of
Peter's proposed text:

"The following state tables specify the behavior of coordinators and
participants when presented with protocol messages or internal events.
These tables present the view of a coordinator or participant with
respect to a single partner.  A coordinator with multiple participants
can be understood as a collection of independent coordinator state
machines <addition>, each with its own state. </addition>."

In summary, I propose a resolution to this issue as follows:
1. Append the text "each with its own state" to the first paragraph of
section 10.
2. Replace "Note 2" of section 10 with "The "Internal events" shown are
those events, created either within a TM itself or on its local system,
that cause state changes and/or trigger the sending of a protocol
message."


Ian



 

             "Newcomer, Eric"

             <Eric.Newcomer@io

             na.com>
To 
                                       "Peter Furniss"

             13/06/2006 19:13          <peter.furniss@erebor.co.uk>,

                                       <ws-tx@lists.oasis-open.org>

 
cc 
 

 
Subject 
                                       RE: [ws-tx] RE: State table
intent  
                                       (was RE: [ws-tx] Issue 036 -
WS-AT: 
                                       Coordinator state machine

                                       incomplete)

 

 

 

 

 

 





Peter - I think that sentence amounts to overspecification.  I do not
regard our spec (or any other interop focused spec for that matter) as
needing to constrain implementation by stating what one cannot do.  I
think the spec needs to define the expected behavior, what an
implementation should or must do, but adding such a "must not" is not
necessary and in fact introduces unnecessary burden on the implementor.

Eric

+1 781 902 8366
fax: +1 781 902 8009
blog: www.iona.com/blogs/newcomer
Making Software Work Together (TM)

From: Peter Furniss [mailto:peter.furniss@erebor.co.uk]
Sent: Monday, June 12, 2006 10:58 AM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] RE: State table intent (was RE: [ws-tx] Issue 036 -
WS-AT:
Coordinator state machine incomplete)

I was going to put something to capture what seemed to be an emerging
consensus at the f-t-f on some specific changes to the state tables, but
before I do, I'd like to know if the assertion:

"Although the states and internal events are modelling abstractions, an
implementation must not make state transitions or send protocol messages
other than as permitted by these tables"

is considered true or false.

(of course, if there was an emerging consensus, it's open to anyone else
to suggest text)

Peter


From: Peter Furniss
Sent: 08 June 2006 10:57
To: 'Ram Jeyaraman'; ws-tx@lists.oasis-open.org
Subject: State table intent (was RE: [ws-tx] Issue 036 - WS-AT:
Coordinator state machine incomplete) Following the discussion at the
end of the f-t-f, I believe the first thing we need to get quite clear
is what the state tables are intended to do - the second being to make
sure the text makes it clear what that is (if it doesn't currently) and
the third to make sure the tables correctly deliver their intent (if
they don't currently).

I believe it was the consensus that
    the tables are to define the externally visible behaviour on a
single coordinator:participant relationship
    there is a separate Coordinator view state machine for each
participant (with independent states)

It was also said that the tables "did not cover all the internal
behaviour"
of an implementation

Although that last statement is undoubtedly true, I think it needs a bit
of clarification. In particular, we cannot state that the act of sending
a message is "internal" - it is obviously externally visible. Thus any
sending of a message needs to be justified by an entry in the state
table that permits the sending. In consequence, although states are in
one sense internal, if the state table is to mean anything, the
transitions between states have to be regarded as externally visible.
The actual stimulus both to change state, and to send the message may be
internal. And of course the state itself is a modelling abstraction - it
may not really correspond to a value held in the machine (it might be
implicit in a "program counter" for example).

If we don't regard the state transitions as external - i.e. we allow
that an implmentation may make arbitrary transitions that are not
reflected in the state table, then the table becomes a nonsense. For
example, an implmentation could do the sequence send Prepare, send
Commit, receive Prepared, send Rollback, send Commit  by asserting that
it had made legitimate (but hidden) internal transitions thus permitted
such.


Is this the consensus ?  If it is, then I think it would be helpful to
expand the introduction text to the state tables to say so (if it isn't,
then it is absolutely essential to expand that introduction to say what
we eventually agree the table scope is).

I'd suggest adding text at the end of the first paragraph of clause 10 :
The following state tables specify the behavior of coordinators and
participants when presented with protocol messages or internal events.
These tables present the view of a coordinator or participant with
respect to a single partner.  A coordinator with multiple participants
can be understood as a collection of independent coordinator state
machines <addition>, each with its own state. Although the states and
internal events are modelling abstractions, an implementation must not
make state transitions or send protocol messages other than as permitted
by these tables</addition>.


We may want to re-arrange or expand that further, especially to explain
more fully what sort of real events are abstracted by the internal
events.

If we are agreed that all sending and transitions have to be supported
by the state table, we then need to make sure all legitimate events are
shown.
If we don't agree, I will propose deleting the state tables as they are
only confusing.

Peter






From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
Sent: 28 March 2006 19:17
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] Issue 036 - WS-AT: Coordinator state machine incomplete
This is identified as WS-TX issue 036.

Please ensure follow-ups have a subject line starting "Issue 036 -
WS-AT:
Coordinator state machine incomplete".


From: Peter Furniss [mailto:peter.furniss@erebor.co.uk]
Sent: Monday, March 27, 2006 1:06 PM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] New issue: WS-AT: Coordinator state machine incomplete

Issue name -- WS-AT: Coordinator state machine incomplete

PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL
THE ISSUE IS ASSIGNED A NUMBER.

The issues coordinators will notify the list when that has occurred.

Target document and draft:

Protocol:  WS-AT

Artifact:  spec

Draft:

AT spec cd 1

Link to the document referenced:

http://www.oasis-open.org/committees/download.php/17325/wstx-wsat-1.1-sp
ec-cd-01.pdf

Section and PDF line number:

section 10, lines 493 - 510


Issue type:

Design / Editorial


Related issues:

New issue: WS-C, WS-AT, WS-BA: Term "Coordinator" overloaded New issue:
WS-AT: Register/Preparing in coordinator state table problematic


Issue Description:

The WS-AT coordinator state tables do not provide explanation of what
the states or internal events are, and do not provide specification of
the interactions between the completion, volatile and durable protocols.



Issue Details:

The WS-AT state tables are described as showing " the view of a
coordinator or participant with respect to a single partner. A
coordinator with multiple participants can be understood as a collection
of independent coordinator state machines". In fact they appear to use
the states and internal events of the multi-lateral coordinator but
inbound events for a single partner. In the absence of any explanation,
especially of the internal events, this is confusing (and there seem to
be some inconsistencies).

There is also little or no specification in the state tables of the
interactions between the completion, volatile and durable protocols
(which essentially determine that the transaction is atomic).


Evidence of multilateralism:
 A bilateral state engine will move from None to Active on receiving
Register. "Active" thus has to be interpreted as the state of the
multilateral coordinator.
 Receipt of ReadOnly would cause a bilateral state engine to go from
Active to None - the tables show it as having no effect on the state.

Lack of protocol interaction
 the tables provide no specification of the volatile-first behaviour -
except perhaps in the Register/Preparing cell, which is cannot be
harmonised with the rest of the table (see separate issue)

 if "User Commit" is to be interpreted as Commit on the Completion
protocol (or its non-standardised equivalent), then a Prepare shouldn't
be sent to a Durable Participant until all the Volatiles have replied.

 The Commit Decision event is presumably meant to occur when all
participants have replied Prepared or ReadOnly, but according to the
state table it could occur any time after Prepare has been sent.

Proposed Resolution:

Create separate tables for the multilateral and bilateral relationships,
and define what all the states and events mean.




  

2006-05-15.Participant.definition.doc