Comment on goals

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

Mark,

It's not clear to me that the protocol for "business transactions" needs
to be mentally or practically segregated from a protocol for ACID
transactions.

I would prefer an approach which seeks to_enable_ looser models, but
_retains, incorporates and supports_ as much of the well-understood
framework provided by conventional transactional protocols as possible.
This is less restrictive, and I think is also likely to be easier to
assimilate for implementors and users alike. It  would allow desirable
interoperability with existing resource managers and transaction
domains.

From a protocol perspective it seems very likely that the conventional,
well-understood 2PC exchanges can be used to enable any of the scenarios
or models so far discussed or entered into this TC's work.

The critical point here is that all the ACID properties are produced,
not by the protocol's message set or sequencing, but by the contractual
commitments of the actors (i.e. by cooperation of coordinators and
participants expressed in unanimous outcome determination by the
coordinator, and by the application of isolation and durability
properties by participants). If this is true, and a new protocol is
specified (as you suggest) in a way which does not constrain
implementations, then we will be able to produce a protocol which can
generate different meanings and effects by applying different contracts,
including the ACID contract.

In this scheme support for ACID is not privileged over other models, but
neither is it discriminated against. In my view, the customer or vendor
should choose which models they wish to use or support (and this is a
useful area for implementation variation). A final qualification: the
overall focus is clearly the "new arena", not the old one. If marrying
the two twists us into pretzels, then that won't be productive. I
suspect, however, in this case that simplicity will run hand-in-hand
with commonality.

I am making several assumptions, some of which are worth stating in this
very brief summary:

The first is that rollback is a special case of backward compensation.
i.e. that the distinction between compensation and rollback is, at a
useful level of abstraction, of no importance (and hinders a useful
generalization).

At a different level of abstraction the potential loss of atomic effect
(you may be able to tell that the failed action occurred), is of course
very important, but in this environment we precisely "want to" (are
forced to) deal with less complete consistency. (We have a "fragmented
consistency" requirement: there may be no single "consistency domain" in
multi-organizational or cross-departmental cohesions).

The second is that "cracking open" outcome determination (the result of
polling participants) is a key enabler. If the application (perhaps
assisted by some well-known pattern or style of outcome determination)
can apply an arbitrary outcome algorithm, then applications such as
"selection from quotes by price", _as well as_ "all or nothing", can be
accomplished readily.

The third is that the protocol message set and sequencing will probably
vary from that of other transactional domains (to the same kind of
extent that existing, conventional transactional domains have
variations) but can be effectively interoperable with them assuming the
usual bridging techniques are applied.

One area which therefore bears examination is: "is there a requirement
or use-case which mandates a transaction model that cannot be supported
using the 2PC scheme for polling readiness?"

Another area that requires special examination is nesting and
sub-transactions more generally. I'd like to get a chance to talk about
that somewhere in the agenda on Tuesday.

Yours,

Alastair