Re: draft-ietf-ldapext-ldapv3-txn-00.txt More ..

["Ed Reed" <ED_REED@novell.com>]

There are application uses for which 2 phase commit for directory updates would be useful.  I just hope to continue avoiding them as long as possible.

There are other application uses in which client applications of the directory would like an XA-like assurance that the updates made to the directory are indeed commited and safe.  These may be more interesting, and don't necessarily require 2 phase commit coordination among all the replicas of a directory partition.  Basically, if DAP / LDAP could participate (via some wrapper, no doubt) with a TPM so that changes against your relational database were coordinated with changes to the directory, I can think of several good uses of such a thing.

But, requiring that all the replicas of an object be connected, on-line, and participating in a 2 phase commit transaction in order to change a object attribute value, or to create a new object, or whatever, seems more than is necessary for most DIRECTORY applications.  I've found that such tight consistency can be had, at the expense of some availability in the face of network outages, via using a "high confidence" option on DAP/Novell's NDAP to force operations against the master replica of the data.  I would note that the loss in availability is actually very small, or perhaps even better than would be achieved with 2 phase commit if all replicas have to be on-line and willing to conduct the operation.

Can we limit the discussion of LDAP transactions to making it so that a client speaking to a single update-able replica (master or otherwise) of the object can coordinate, via 2 phase commit semantics and protocols, the update of the directory with other XA-fluent databases/transactions?  And NOT attempt to address, for now, the nesting of transactions through the directory to all of it's replicas and/or downstream event notification consumers (and audit facilities)?  

Ed

-------------------
Ed Reed, Technologist
Group Technology Office
Novell, Inc.
+1 801 861 3320

>>> Prasanta Behera <prasanta@netscape.com> 04/14/1998 14:25:24 >>>


David Boreham wrote:

> Harald Tveit Alvestrand wrote:
>
> > Small comment:
> > Might the DSAs use a transaction protocol such as that described in
> > draft-lyon-itp-nodes-07.txt to coordinate the locking between them?
> >
> > The span would go roughly between Client, Server1 and Server2:
> >
> > Client -> Server1: Start transaction
> >        <- OK
> > Client -> Server2: Join transaction
> > Server2 -> Server1 (TIP): Join
> >         <- OK
> > Client <- Server2: OK
> > Client -> both servers: Stuff
> > Client -> Server1: Finished
> > Server1 -> Server2: OK to finish?
> > Client -> Server2: Finished
> > Server2 -> Server1: Yes, I'm OK to finish
> > Server1 -> Server2: Let's do it
> > Server2 -> Server1: OK, it's done
> > Server1 -> Client: OK
> > Server2 -> Client: OK
> >
> > This is fairly standard technology, I believe.
> > It's getting the details right that hurts.
>
> I believe this is a form of 2-phase commit,
> which the document specifically doesn't address.

That sounds right.  Do we expect  directories to have thesame kind of
requirement like the traditional databases ?  The DB
world moved away from 2pc to replication as 2pc  introduces
interesting problems.  That doesn't mean that 2pc are invaluable.
My question is do we see the need for 2 pc for directory application.
It will be nice to have some examples where it will be benifical
(at least it will help me).

With referrals,  2 pc can get messy as we chase servers.
My take would be to keep directories simple.

/prasanta