Re: LDAP vs. Relational

["Mark Wilcox" <mark@mjwilcox.com>]

Hi,
There's nothing in LDAP that handles concurrent access. I'm pretty sure the
IETF Directory group is working on it though (as part of developing a
standard for LDAP transactions). Currently I'm pretty sure most servers
won't allow dual write at the same time, but rather delay the writing of the
second update until the first one is finished.

If your LDAP server can support LDAPv3 and it supports an API for adding
server plugins you can develop a server control or an extended function that
would enable you to implement a "write" lock on the database.

Mark
-----Original Message-----
From: Luca VEZZADINI <GVEZZADINI@businessobjects.com>
To: openldap-general@OpenLDAP.org <openldap-general@OpenLDAP.org>
Date: Thursday, May 06, 1999 6:01 AM
Subject: RE: LDAP vs. Relational


>Hi all,
>this is very interesting, indeed. And I think I have an extra question to
>raise here, as it relates to this thread.
>
>LDAP is optimized for read access as write operations are less frequent.
But
>does it provide any lock mechanism for concurrent write access? That is a
>very delicate point. Even if we can live without transactions, we must
>guarantee that concurrent write operations don't mess data. If two
>operations have to update an entry at the same time, what happens?
>
>Maybe LDAP simply relies on the fact the directory data must be carefully
>designed, so there will always be exactly one data owner for each attribute
>in the schema. If that is the case, the risk if very high, in my opinion.
>
>    Luca
>
>
>-----Original Message-----
>From: Mark Wilcox [mailto:mark@mjwilcox.com]
>Sent: Thursday, May 06, 1999 8:21 AM
>To: Tod Thomas; openldap-general@OpenLDAP.org
>Subject: Re: LDAP vs. Relational
>
>
>Hi,
>Well you are partially right.
>LDAP is a protocol. What LDAP really provides is this:
>a common means of access to objects over the network via an open standard
>protocol.
>
>Where LDAP really pays off is when you have information that is read more
>often than written to (though the write performance is improving).
>
>An API just makes it easier on the developer to communicate with a
directory
>server via LDAP (much in the same way a telephone makes it easier to
>communicate with your mom via your native language).
>
>In the LDAP gateways that I have tested against they work ok if you need to
>get access to an existing database of email addresses or a small set of
>userids for authentication. They just don't peform very well when put under
>a serious load, nor do they usually fully support the full LDAP v3
>specification. This is because things like RDBMS are optimized for
>transactions and complex relational queries while LDAP is designed for very
>fast lookup of information.
>
>That being said, a RDBMS is usually a good solution for a "registery". A
>registery is a database where you first combine your data and then publish
>into your LDAP server for interfacing. RDBMS work well here because they
>usually have better write perfomance, but better they have transaction
>control, something LDAP doesn't have (yet ;).
>(Thanks to Jeff Hodges at Standford for the registeries concept).
>Here's a good info on the importance of a registery in the implementation
of
>LDAP
>http://www.stanford.edu/group/itss-ccs/project/registry/
>
>If you are thinking of using LDAP to build your infrastructure (e.g. single
>logon, certificate management, etc), it's better to go with a "pure"LDAP
>server. They will be optimized for LDAP performance (just as a Web server
is
>optimized for HTTP performance and HTTP gateways on other systems are not).
>This is just like using a real saw to cut a piece of timber because that's
>what it's made for. A LDAP gateway on an existing database too often is
like
>using that little puny saw you find on a Swiss Army knife. It cuts a few
>things, but you wouldn't want to build a house with it. ;)
>
>Hope that helps.
>
>Mark
>
>-----Original Message-----
>From: Tod Thomas <tthomas@chubb.com>
>To: openldap-general@OpenLDAP.org <openldap-general@OpenLDAP.org>
>Date: Monday, May 03, 1999 7:12 AM
>Subject: LDAP vs. Relational
>
>
>>First, let me apologize if this question sounds a bit naive or has been
>>asked before.  It came up in a meeting I attended a few days ago and I
>>think it is relevant.  I  have to admit I don't have a complete answer
>>and thought it would be best to present it to a larger community to get
>>a broader perspective.
>>
>>I've been involved in directory services using LDAP off and on for about
>>a year now.  My approach has been that LDAP provides a centralized
>>resource of relatively static information that can be easily accessed by
>>a standard set of API calls. With that in mind I have implemented a
>>directory that has H/R information that can be shared over our Intranet
>>and accessed using a standard web browser.
>>
>>However a larger number of software manufacturers, relational database
>>in particular, are marketing themselves as LDAP compliant.  The LDAP
>>API's can be used against a relational database and data will be
>>returned as if it was a directory.  I've done this against a Lotes
>>Domino database and although limited, it works satisfactorily.
>>
>>The question is this:  If I can get information that I could store in
>>the directory from an LDAP compliant database using the API calls what
>>would be the point of installing and supporting a directory ?  Would it
>>not then be reduced to a programming exercise of pointing your
>>application to the named database that has a version of slapd running?
>>
>>Please enlighten me.  I think my efforts and my time invested thus far
>>have been worthy but I need to provide better justification if I want to
>>expand the scope of my work so far.  Thanks in advance for any help or
>>opinions.
>>
>>Tod Thomas
>>
>>
>
>