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 16:52:50 GMT
Ole,

Comments inside your mail...

On 3/21/07, Ole Ersoy <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

Mime
View raw message