Re: Write-intensive LDAP

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

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

> Hello,
>
> Although it is common knowledge that LDAP is mainly used for applications
> that are almost read-only, I wonder if that is more than a cultural issue.
>
> I'm designing a directory holding certificates, but it would suit me rather
> well if I could put payment information and sales progress information in
> there as well.  So that it could be accessed by resellers in a standard
> format, rather than through some crummy web interface that half of the
> resellers would parse with Perl.
>
>  (Resellers are to act on behalf of OpenFortress in selling its digitally
>   signed products, and would therefore have access to the LDAP directory,
>   or a specific corner of it meant for resale.  Orders, when they are not
>   finalised yet, tend to go through phases, and would be changed by
>   different parties while doing so.  This is a specific example of a
>   workflow application, I suppose.)
>
> 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, that write more
> often than a phone book changes.  When I look at the OpenLDAP software
> though, and I bet other software behaves similarly, it is not very good at
> processing many writes.  I am unsure, but this may be a backend issue, and
> it could perhaps be solved with a specific backend for the reseller corner
> of the directory, that welcomes writes and is less eager to build indices
> than OpenLDAP usually is.

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

- Booker C. Bense