Re: Write-intensive LDAP

["Booker C. Bense" <bbense@networking.stanford.edu>]

On Tue, 17 Sep 2002, Rick van Rein wrote:

> Hi Booker C. Bense,
>
> > > As far as I can tell from the LDAP protocol spec and the C API spec, there
> > > is no technical hindrance that would stop apps like this [...]
> >
> > - Read the protocol more closely. There is no support for transactions
> > or locking.
>
> I don't think that would have to be a problem.

- Then I don't see much point in discussing this. If your system
doesn't need transaction support or record locking, then a
write-enhanced LDAP might work. If you can guarantee that two clients
will never attempt to write to the same record at the same time,
then LDAP might be okay.

> > Any system that writes
> > extensively to LDAP needs to support a complete rollback/queueing
> > implementation outside of the protocol.
>
> What would it add, given that the writes are more-or-less independent
> and interchangeable?

- You have no guarantee that writes will succeed. LDAP servers go
down, networks partion, the real world intrudes.

>
> > 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.
>
> Don't you mean that it's a property of a certain implementation, such as
> LDAP?  I see nothing wrong with the current protocol (as explained above)
> and they don't make protocols that rely on such subjective grounds as
> "infrequent".

- Yes, they do. Every protocol has hidden assumptions about how it's
going to be used. LDAP assumes WIRM, otherwise it would have support
for record locking. Many people have been down this path already,
ignore their experience at your own risk. Openldap is "slow" at writes
because it's attempting to the most reasonable thing in the face
of potential problems in the protocol.

- Booker C. Bense