Re: Your proposal

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

I think this discussion is entirely superseded by yesterday's call.

Mark Little wrote:

> If someone has some minutes from yesterday's teleconference I'd appreciate
> seeing them.
>
> However, in case this didn't come up:
>
> > I agree with you (and Mark) on not changing BTP's 2PO (two phase outcome)
> > protocol, and as it should be clear now that I do not propose a 3PO
> protocol
> > for BTP. Your proposal addresses my concern and is essentially what I was
> > also going to propose at today's conf call. If there is no FINAL_OUTCOME
> > request from the participants then the business is as usual, otherwise as
> > you suggested superior sends a FINAL_OUTCOME to those participants which
> > requested it.
>
> Stepping back a little, what is it you are trying to achieve?
>
> It seems like what is happening here is that we had a cohesive application
> that involved multiple participants who had not been grouped together
> arbitrarily: they form an application to accomplish a specific task, e.g.,
> order books, buy insurance, and arrange delivery. Only the entity that
> grouped these services together (let's call it a client) knows what it means
> to him/her to talk to all of these services as a coherent grouping:
> individually they do not accomplish the whole task.
>
> Now we are saying that if a single participant failure occurs (e.g., the
> insurance service) in the final commitment phase of this application (after
> all participants said "OK" to PREPARE) some subset of the other participants
> should be informed by the transaction service so they can do what?
> Individually they can't fix the problem, since this requires global
> application knowledge only really held by the client. Who is to say that the
> failure of a participant actually requires the other participants to
> automatically compensate? This cannot be down to a participant. In this
> example, as a user I should be given the opportunity to compensate my own
> *application* or not: losing insurance may not actually be such a bad thing
> if I'm willing to take the chance that the books get delivered OK. The book
> service (actually the participant) does not know this and never can at the
> BTP level. In addition, tet's not forget what I said yesterday about the
> difference between a participant's knowledge and a service's knowledge.
>
> What this proposal would do, if enacted, would be to break the abstraction
> of application domain knowledge and BTP specific information, opening up a
> bigger can of worms than we already have. How at one level can we say that
> BTP provides a way of grouping together services to accomplish a task (which
> must be specified by the grouper) whilst at the same time saying that if
> certain failures happen the grouper has no control over what non-failed
> participants are going to do to *his* work?!
>
> >  I think the only minor difference between your proposal and
> > mine would be that if CONFIRMED include a request to know the
> FINAL_OUTCOME
> > then I think the superior should send it, not optional; unless the
> > participant knows the intention of the superior it may end-up holding the
> > logs for ever..
>
> If the coordinator has to deliver this message then it will affect the
> performance of the system as a whole.
>
> Also, what happens if these FINAL_OUTCOME messages don't get enacted upon?
> Is it synchronous, i.e., is there a FINAL_OUTCOMED (?) from the participant
> back to the coordinator to say it has happened? Is delivery good enough? I
> doubt it.
>
> What happens if more than one participant wants to be informed of this
> heuristic failure so that they can compensate? Should these compensations be
> atomic/cohesive? Who is coordinating them? What if the compensations fail,
> i.e., the participant cannot undo its confirmation? What if only a subset of
> the compensations fail?
>
> These are only a few of the questions that need to be answered. If the
> overall answer is that it's only an informative message then we should not
> be doing it at the level of BTP.
>
> Mark.
>
> ----------------------------------------------
> Dr. Mark Little
> Transactions Architect, HP Arjuna Labs
> Email: mark@arjuna.com | mark_little@hp.com
> Phone: +44 191 2064538
> Fax  : +44 191 2064203
begin:vcard 
n:Green;Alastair
tel;cell:+44 795 841 2107
tel;fax:+44 207 670 1785
tel;work:+44 207 670 1780
x-mozilla-html:FALSE
url:www.choreology.com
org:Choreology Ltd
version:2.1
email;internet:alastair.green@choreology.com
title:Managing Director
adr;quoted-printable:;;13 Austin Friars=0D=0A;London;;EC2N 2JX;
fn:Alastair Green
end:vcard