Re: Your proposal

[Sazi Temel <sazi.temel@bea.com>]

Mark,
I think my reply to you never made the list.. and I am resending it. I read 
your and Alastair's e-mail on ' discussion is entirely superseded by 
yesterday's call', I am sending the e-mail anyway, since I think, what has 
been discussed yesterday and what the implications are, is not clear - at 
least as far as this discussion goes.

Regards,
--Sazi

----------------// -------------------

At 02:37 PM 10/5/01 +0000, 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?

I will try not to go into other directions other than what is
discussed technically, in the rest of email and discussions. It is clear
that the proposal as shown above is very much aligned with what I was
proposing


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

With above proposal only those participants which requested to be
informed will be informed. Since they requested it they know what to do.


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

Nobody is saying that in case of a failure of one participant, all
the others will compensate, only those that requested may compensate. I say
may, we do not know what they will do, as you say we do not know the details
of this service. With this proposal we are now able to let the participants
know that the 'real' state of the transaction.


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

This proposal (although applicable for Cohesion) was for atomic BTP
(Atoms) and per definition of atom, if one participants fails the atom is
broken, there is no multiple successful outcome for an atom as there is for
Cohesion thus it is not (at least for Atom) a decision to be made by
application level.


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

See above comments.. It will not break any application domain
knowledge.


>If the coordinator has to deliver this message then it will affect the
>performance of the system as a whole.

Yes there is some performance penalty, not sure how much.. What will
we choose, consistency or performance at this particular situation..? There
are places that one will definitely choose performance and places that one
will choose consistency; For this particular case I would choose to beware
the consistency of the Atom - as much as possible.

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

I am not suggesting any particular action to be taken by the
participants, they can do what ever they want to do, compensation or
something else. Coordinator only informs the participants on what has
happened to transaction - noting more.



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

There are many situation like you have described above in BTP. These
questions are addressed in BTP doc relevant sections on recovery (see state
diagrams). Mark, I think your concern is valid for Cohesion... for Atom we
should do as proposed..


>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

-------------------//-------------------