directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole.er...@gmail.com>
Subject Re: [LDAP DAS] Efficient Updating of Persisted Objects
Date Wed, 21 Mar 2007 18:19:54 GMT
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.

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.

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.

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

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.

 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?

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

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

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

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

- Ole



Emmanuel Lecharny wrote:
> Ole,
>
> Comments inside your mail...
>
> On 3/21/07, *Ole Ersoy* <ole.ersoy@gmail.com 
> <mailto:ole.ersoy@gmail.com>> wrote:
>
>     <snip/>
>
>  
>
>     SCENARIO-UPDATE
>     <snip/>
>     Suppose there was an ObjectClass
>     defined in ADS called
>     Address.
>
>     Then when we did the read operation instead of
>     deserializing/unmarshaling the object,
>     we would grab the list of attributes on the entry, pass them to
>     the DAS,
>     and the DAS would instantiate
>     the corresponding object for us.
>
>
> This is something we might consider. Right now, we don't do that 
> because it does not make a lot of sense. Again, an entry is generaly 
> small, so grabing one attribute or the whole entry makes no difference 
> compared to the IO cost (reading some object from disk will be 
> thousand time slower than doing any in-memory manipulation). If we 
> have bigger objects, with bigger values (JPegPhoto for instance), 
> then, yes, we have to do something. But we are already thinking about 
> serializing such objects in streams which will be separated from the 
> entries.
>
>     (The DAS would then use the setters on the object
>     to set those attributes per a predefined map, using
>     annotations on the object or an xml configuration file.)
>
>
> We should avoid reflection as much as possible. Even in Java 1.5 it's 
> damn costly. We have our own serialization of objects, and we are 
> using it. Now, we want to extend this mechanism to all the 
> attributeTypes, because the gain is enormous (I have been able to 
> speedup the server by 50% just using the serializer for Attributes)
>
> If we switch to another internal structuration for objects (have a 
> look at 
> http://cwiki.apache.org/confluence/display/DIRxSRVx11/Backend), then 
> using some other mechanism may be interesting.
>
>     So now when we update street, we would only send that updated
>     attribute back to ADS.
>
>     This leads me to the next scenario which is outside of CRUD:
>
>     SCENARIO-CREATE-SCHEMA:
>     This is similar to the creation of a RDB Schema or XML Schema,
>     but instead of creating these, it's a LDAP Schema defining
>     new ObjectClasses that correspond to the objects we are persisting.
>
>
> In fact, in Ldap, this is exactly what we have : you can't create an 
> object if the schema does not contain the attributeTypes and 
> ObjectClasses. The new system, available in 1.5.0, allow you to define 
> a new ObjectClass, or AttributeType, store it into ADS itself, and 
> then create instances of thise newly created ObjectClass
>

>     These would be written to ADS so that attributes of the objects
>     could be stored the same way we store instances of ObjectClasses
>     at some DN location.
>
>
> Don't understand what you mean.
>
>     Does that make sense?
>
>     We are now using ADS as an RDB essentially.
>
>
> ADS is really close to a RDB. It has a master table storing all the 
> entries, and many BTrees indexing all the needed attributes.
>
>     More like an Object Oriented Database actually.
>
>
> Hierarchical databes is much closer to  the reality.
>
>
>
> -- 
> Cordialement,
> Emmanuel L├ęcharny
> www.iktek.com <http://www.iktek.com> 


Mime
View raw message