Re: Global view requires transactions (RE: Use Cases )

> > They are different precisely the manner I outlined (though
> > perhaps didn't give enough text): the latter case does not
> > require a separate coordinator as its functionality may very
> > well already be built into the business logic. We are working
> > with companies that do not need a separate coordinator (or
> > transaction) service whether that is based on BTP or WS-T:
> > they have spent many years on developing in-house management
> > systems that do this for them and do it very well (and in the
> > presence of failures).
>
> ok - if the point was the separate coordinator. But the "separate
> coordinator" may be just a separate object in the same process. That's
> quite orthogonal to the message exchange between the client-side as a
> whole and the service-side as a whole, which you also showed as
> different.

They are different if the coordination aspect has already been solved within
the business domain. Of course if that is a co-located (in process)
coordinator or a bespoke solution the message exchanges are similar. But my
point is that the right approach is not to force a coordinator
service/solution: one may already exist implicitly.

>
> >
> > > Actually, I'm especially intrigued that Mark doesn't count that as
> > > being "two-phase".
> >
> > You are correct and wrong: firstly this is a two-phase
> > approach; secondly I did not say it wasn't two-phase in my
> > original email!
>
> Sorry - you identified the first explicitly as two-phase, and I thought
> that was part of the distinction.

No.

>
> > > There's obviously a double exchange, and it's clear the
> > service passes
> > > through a "doubt phase", where it's waiting on the leftside
> > to confirm
> > > (or presumably, cancel) the order. To me, that's two-phase
> > - there's a
> > > request for work to be performed contingent on a later yes/no, then
> > > the yes/no. Whether there's an explicit prepare signal, or
> > whether the
> > > coordinator could be separated (or, as here, is integrated on the
> > > left-side) are particulars that don't affect the principal.
> >
> > Again, correct. However, in this case it's two-phase, but
> > there are situations where it isn't and BTP (since I'm
> > assuming you're pushing that) isn't appropriate.
>
> Not exclusively BTP, but every coordination case we've come across seems
> to end up with the contingent, then yes/no phases.

Many do, and just as many have phases within the "transaction" (deliberate
use of quotes) such as "are you still good to go?"

> Using that as the
> defining characteristic of two-phaes, are there really others ? Or is it
> a question of terminology, that a more restrictive (and no doubt useful)
> definition of two-phase would give a different classification.

From experiences it is inappropriate to assume a "transaction" has just a
start and end phase (even if that end phase is split into prepare, confirm
and cancel with arbitrary times between them).

Mark.

Received on Thursday, 22 May 2003 10:17:20 UTC