directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <elecha...@gmail.com>
Subject Re: [LDAP DAS] Efficient Updating of Persisted Objects
Date Wed, 21 Mar 2007 18:44:43 GMT
On 3/21/07, Ole Ersoy <ole.ersoy@gmail.com> wrote:
>
> Emmanuel,
>
> I think my squirrel brain is starting to put together what you are
> saying :-)
>
> Let me see if I'm getting it.
>
> ATTRIBUTES VS. ENTIRE OBJECT
> Whether we pass an entire object or an individual attribute to ADS when
> updating,
> performance wise there's probably no difference since it's such a small
> chunk of info.


In fact, we pass attributes and we update them in a whole object before
storing it. To be able to do that, we first have to get the whole object out
of the backend. For instance, if you want to add a userPassord to the
uid=oersoy, dc=apache, dc=com entry, you will just pass a modifyRequest with
the DN, and the userPassord attribute with the value to add. Then the server
will search for the corresponding entry from its DN, and if found, it will
read it entirely. Then it will add the attribute into the entry, and save it
into the backend.

This applies at when ADS serialized to disk and when the Application
> sends data to ADS
> via the directory context per the criteria that object's size is below a
> certain number of KB.


Well, the criteria must still be implemented ... It's now 2 years we know we
have to deal with such a criteria, but we didn't had time to implement it
yes... 1.5.2 maybe

So from a "Passing the Baton" point of view, it does not matter whether
> it is a attribute or
> an object...since their size different is typically so small.


We can say that

Since this is the case, then the DAS implementation will be really
> straight forward I think.


Well, it's pretty much done in two classes only, AttributesSerializerUtils
and AttributeSerializerUtils. Only 700 lines of code, javadoc included :)

I'll just skip commenting on the rest of your in lined comments, if I
> understand correctly,
> since the rest is not really important anyways.
>
> JUST A SIDE NOTE:
>
> RDB Backend for ApacheDS
> If we did this, then passing an attribute instead of an Object might
> make sense, if I understand correctly.


yep.

>From what I understand rear ends like Prevayler
> are thousands of times faster than any RDB, even if the entire RDB were
> stored in main memory (Like with hsql),
> so would there ever be a point in using an RDB?


There are many, including high volumes, reliability, replications,
marketing, "We already have Or*cle/I*m db*/MySql/PostGresql" (TM), ...

I mention this because Tuscany also has a DAS for RDB.


We have had discussion with Tuscany guys in Austin about including ADS into
tuscany.

So an SDO model could serve as a middle tier between RDB persistance and
> LDAP persistance.


That may be a very good idea, because then it may abstract totally the
plumbery between ADS and the backend. At the moment, this plubery is not
really satisfactory.

Applications that need an RDB rear end, could pull info out of ADS using
> the
> DAS for LDAP, and store in in any RDB using DAS for RDB...


Yep.

Anyways, should probably put that in a different thread or JIRA or
> something...or the ADS
> design document that I need to get started...


We are seriously thinking about it for a 2.0 version of ADS. We might
discuss this  in may, during ApacheCon (if the number of beers we will
absorb, not to mention the strange substances we will smoke, keep our brain
productive :)


-- 
Cordialement,
Emmanuel L├ęcharny
www.iktek.com

Mime
View raw message