[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Write-intensive LDAP

On Tue, 17 Sep 2002, Howard Chu wrote:

> > -----Original Message-----
> > From: owner-openldap-software@OpenLDAP.org
> > [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Booker C.
> > Bense
> > On 17 Sep 2002, Tony Earnshaw wrote:
> >
> > > tir, 2002-09-17 kl. 19:42 skrev Booker C. Bense:
> > >
> > > > - Read the protocol more closely. There is no support for transactions
> > > > or locking. You will have a hard time building a robust system with
> > > > lot's of writes without those primatives. Any system that writes
> > > > extensively to LDAP needs to support a complete rollback/queueing
> > > > implementation outside of the protocol. Speed is not the problem,
> > > > consistancy is what will bite you in the long run. LDAP works fine
> > > > for WIRM applications ( write infrequently read many), it breaks
> > > > horribly for write intensive applications.
> > >
> > > This hasn't got much to do with the protocol IMHO, everything to do with
> > > the choice of database. BDB 4.0.14 does, indeed, have fine-grained
> > > locking and transactional (roll-back) logging.
> > - The problem is not consistancy of the database in current software,
> >   it's consistancy of the information. There's no way for your
> >   application to have any guarantee that the data it reads back,
> >   is the data it's written. If that's not a requirement of the
> >   application then ldap may be perfectly acceptable.
> NFS doesn't provide this sort of guarantee either, but people manage to get
> by with it. The whole "last-writer-wins" philosophy has been part of Unix
> since the Beginning of Time.

- File locking has been in unix as long as I've known about it. There
are applications where "last writer wins" doesn't work. NFS does have
file locking and in modern version it even works.

> If you update an entry and then someone else
> updates the entry 5 msec later, and then you read the entry, certainly you
> won't see the data you just wrote. If you need some other kind of behavior
> you can implement it at your application level. Of course, if you have an app
> that immediately re-reads what it just wrote, I think there's something
> broken in your app's design; it ought to know what it wrote without
> re-reading it.

- What if the other part of your application is across the country? If
something needs to READ every update, how do you guarantee that
this happens? The WIRM principal applies to a specific piece of
information in the ldap server. If you're writing stuff that
isn't going to change, then yes "lots of writes" is an
implementation issue, not a protocol one.

- Booker C. Bense