directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: [LDAP DAS] Efficient Updating of Persisted Objects
Date Wed, 21 Mar 2007 19:28:41 GMT
OK - Cool - So for LDAP DAS version 1.0
I'll just write the entire SDO datagraph to ADS with each
SDO object being an entry.

Also, (Just wanted to make sure I understand)  are you saying that 
having a RDB backend because of:

High volumes

Makes sense?

Emmanuel Lecharny wrote:
> On 3/21/07, *Ole Ersoy* < 
> <>> wrote:
>     Emmanuel,
>     I think my squirrel brain is starting to put together what you are
>     saying :-)
>     Let me see if I'm getting it.
>     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.
>     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
> <> 

View raw message