Re: Comment on goals

[Mark Little <mcl@arjuna.com>]

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

Agreed. One of the points of the HP proposal was that transactions are good
for a certain class of applications, wherever those applications may run,
i.e., even in a loosely coupled environment. Business transactions may well
want ACID transactions (certainly high-cost "transactions" may well want to
take the penalty of full ACID-ity because of the guarantees they get).
There's no such thing as a free meal in computing either, so you can't have
the guarantees of ACID-ity without the (potential) problems. However, if you
point out all of the pros and cons to someone and let them choose the right
protocol for them then that's the best you can ever do. If I get a chance
before Tuesday I'll take a look at Jim Grey's original IBM technical
reports: he defined 3 levels of "transaction" (and had a different term that
encompassed them all), where ACID-ity was relaxed.

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

Yes. There is essentially a class of protocols which have certain
requirements on persistence, concurrency control etc. and ACID transactions
are one specific implementation. ACID shouldn't be special in this category
just because it was first.



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

I think a specification that cannot work with existing resources and
transaction domains is doomed to failure from the start. We have to work
with "legacy" systems, and what we are about to specify will be legacy next
year!

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

Yes, but not necessarily in the most "efficient" manner (subjective term).
However, as I said above (and in the HP proposal) that shouldn't rule them
out from being used for these applications. You trade something for
"efficiency". I'd like to see a situation where a builder of a "business
transaction" can be presented with a toolkit of extended transaction models
(or even better, if the ones he has don't fit then he can construct new
ones), and can weigh up the pros and cons of each given his specific
requirements. I'm a little bit worried that we may stop at transactions with
compensations, since I think that only addresses a certain class of loosely
coupled applications. However, from a purely pragmatic stand point it's a
start.

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

Exactly. A transaction manager (e.g., one based on the OTS) cannot guarantee
ACID-ity by itself. It has a level of trust in the participants to do the
right thing when send prepare/commit/rollback. Unless we stick the a single
model based upon compensations for traditional ACID transactions, people are
going to have to realise that they're probably going to have to implement
new types of resources for these extended transaction models. However, I
think the benefits far outweigh the implementation cost.

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

Agreed.

> In this scheme support for ACID is not privileged over other models, but
> neither is it discriminated against.

Again, I fully agree.

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

What I'd like to know is the timeline for BTP. Is this likely to be a
rolling specification? If we specify a limited set of models now (even 1,
say), can we keep revisiting the proposal and adding to it? This is my first
OASIS specification, so I don't know the rules. In the OMG world it's
entirely possible via the Revision Task Force route. Does anyone on this
list know the answer?

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

Correct. This is quite a common definition anyway, so we shouldn't have a
problem.

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

And this is exactly what a user/programmer needs to know about as well.

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

One of the reasons I want us to discuss use cases on Tuesday (and assemble
them) is precisely because of this. We need to know what can and can't be
accomplished today with 2PC (I think the answer is "we can do pretty much
everything, but there may be a cost for failures"), and see what the issues
are, and how different models may address them.

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

You know my thoughts on nesting! I think in a loosely coupled environment
nested transactions can really come into their own. From last nights
teleconference the notion of "group" calls out for nesting.

Mark.

----------------------------------------------
Dr. Mark Little (mark@arjuna.com)
Transactions Architect, HP Arjuna Labs
Phone +44 191 2064538
Fax   +44 191 2064203