[Fwd: Your proposal] on behalf of MCL (HP)

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

---

• From: "Mark Little" <mark_little@hp.com>
• To: "Temel, Sazi \(MBS\)" <Sazi.Temel@mortgagefamily.com>,<alastair.green@choreology.com>
• Date: Mon, 8 Oct 2001 10:39:24 -0000

Despite the fact this this may now be moot, it's still an interesting point
of discussion. So, with that in mind ...

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

Fine, but my point is that that proposal and yours are attempting to "solve"
a problem that cannot be solved by an individual participant or subset of
participants, unless we are suddenly introducing a lot more information
about the whole flow and composition of an application to individual
participants. If that's the case then we are into the domain of workflow,
and should let other committees take care of that.

> 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?
>
> Sazi > With above proposal only those participants which requested to be
> informed will be informed. Since they requested it they know what to do.

No they don't! They may know what to "do" on an individual basis, but how
does this related to the entire application? As I said, I will get pretty
p*ssed if am*zon decided unilaterally to "unsend" my books just because the
insurance WS failed to confirm. If that's the approach *I* want to take then
I can do the compensation: am*zon don't have the global knowledge of what
constitutes the application. In addition, remember we have a separation of
web service from participant, so an individual participant may well only
ever do the equivalent of xa_commit/xa_rollback, and not see any of the
business logic that went into the work it is committing or rolling back. So,
how can a participant know what to undo/compensate?

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

So now we go from having a subset of participants that failed to confirm
because of failures (typically I'd hope that would be the case) and the rest
that did confirm, to a grouping of participants that confirmed, those that
didn't because of failures, and those that compensated what they as
individuals did! Pretty hard to grasp what's going on now, I'd say.
Definitely not atomic!!

And what happens if those participants that want to compensate fail? Who is
coordinating that? Is there a compensation for the compensation? Do we then
need to tell the client?

In the end, if you actually *look* at what you want to do, and how it can be
accomplished in a failure resilient and reliable manner, you should
(hopefully) see that what is required is a compensation flow at the
application level, that is driven either by the client, or by whoever
composed the original application in the first place. This will then lead to
a workflow system. This is why transaction systems do not do workflow, but
workflow may well use transactions.

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

I understand this, but now there are multiple outcomes, simply because only
a subset of participants are informed, and there is no coordination of their
compensations at the BTP level.

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

Yes it will. See above.

> Sazi > Yes there is some performance penalty, not sure how much.. What
will
> we choose, consistency or performance at this particular situation..?

Both. Let the application or the application composer determine whether
compensation for the entire atom/cohesion is required, and program
accordingly. Do not impose performance degredation from below.

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

But as I said above, your proposal will blow consistency out of the water,
*unless* we introduce some kind of workflow scheme to coordinate the
compensations and ensure that all participants do the work.

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

But you have not answered my questions. Is this a reliable delivery? Does
the participant have to respond that it has done the work? If it doesn't the
coordinator does not know what state the participant is in, and hence what
state the atom is in.

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

No. Cohesions are certainly an issue, but individual atoms are too. Let's
work up, and concentrate on the atoms. Please provide comprehensive answers
to *all* of the points I raised in this email and the previous one concering
recovery and reliability, and maybe then we can discuss whether this is a
viable option. I still believe it is not.

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