RE: State tables

[Peter Furniss <peter.furniss@choreology.com>]

Mark,

Yes, I agree with the behaviour (though one could make it that the cohesion
composer only persisted the atoms that it would confirm, telling the others
but leaving it to presume abort to sort them out if there is a failure)

This isn't directly stated in the state tables, but will need to be stated
in the explanation of "decide to commit". The state tables are concerned
purely with the communication between two parties (atom
coordinator:participant or cohesion composer:atom coordinator or atom
coordinator: subcoordinator), and the directly related persistent changes.
But how those latter work depends on where/what they are - in particular an
atom coordinator's "decide to confirm" to a participant will typically be
multi-step:
	persist information about the participant(s) and about cohesion composer
	submit its vote
	receive a confirm instruction from the composer

The atom coordinator *MAY* choose to change its persistent information to
show the decision, but given that the composer is doing the right thing
(i.e. following the rules you suggest), the atom coordinator is NOT REQUIRED
to make this change. If there is a failure, the atom coordinator will refind
the confirm decision from the composers persistent information and propagate
it to the participants.

We could have a state table for this kind of stuff as well (such will tend
to have set-based predicates) but it might be clearer to use text.

Peter

> Peter, the state tables look fairly comprehensive, and I haven't had a
> chance to read through them in detail, so what I'm about to re-iterate may
> be implied in them. About two months ago when we started fleshing out the
> BTP I mentioned that a cohesion coordinator, i.e., that entity
> which decides
> to prepare atoms A, B, and C, for example, and then decides to
> cancel A and
> C and confirm B, should make persistent:
>
> (i) information about which atoms it was using that have been prepared.
>
> (ii) what decision it is about to make, i.e., cancel A and C, and
> confirm B.
>
> This is similar to the role an atom coordinator would play, except that an
> atom coordinator simply remembers all of its prepared participants and has
> the same decision associated with them all, whereby the cohesion
> coordinator
> potentially has different decisions for each participant atom.
>
> Mark.
>
> ----------------------------------------------
> Dr. Mark Little (mark@arjuna.com)
> Transactions Architect, HP Arjuna Labs
> Phone +44 191 2064538
> Fax   +44 191 2064203
>
>
>