RE: Write-intensive LDAP

["Howard Chu" <hyc@symas.com>]

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Booker C.
> Bense

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

If you make a request and get a result back, then the operation completed or
was rejected with an appropriate error code. Writes are atomic in LDAP/X.500;
they are all-or-nothing. If you get a "success" result then the write
completed. If you get an error result, then the write was ignored. If there
is a failure somewhere in the network and you get no result, then you won't
know one way or the other, but this is true for any network protocol.

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

The absence of record locking does not have any bearing on whether the
protocol is suitable for a high write frequency. LDAP servers are commonly
thought of as slow for writes because the original UMich slapd architecture
was not optimized for writes. It's slow for writes because creating all the
relevant attribute indices for an entry is a time-consuming process. In my
opinion it's not a property of the protocol, just a characteristic of the
most well-known implementation for so many years. The UMich code base was
little more than a proof of concept; it was persistently non-optimal in most
of its code.

The X.500 design only deals with modifications to single entries. When you
can only affect one entry at a time, and you provide atomic write operations
as LDAP/X.500 does, record locking at the protocol level is unnecessary. Note
that you can use the Modify operation to implement mutexes if you really want
to, but you probably shouldn't be using LDAP if you really need this kind of
functionality.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support