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 16:26:04 GMT

I in-more comments, but am adding a little more context first (It's a 
bit long though :-) ):

The  DAS will do CRUD operations for us.


So if we were to look at this from an Application point of view
we can imagine the following scenario:

There is nothing in ADS.

Our application creates an empty SDO model instance, an address for example.

Then it stores the address under
DN: |uid=address,ou=users,ou=system|

So now we can fetch that address instance from there.

We want the address object so we grab it.

This is the interesting part.

We we are storing the Address object
as a whole, we can update say only
its street attribute, and then overwrite
the entire persisted object again.

But in reality we really only wish to overwrite
the street attribute of the java object.

Suppose there was an ObjectClass
defined in ADS called

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.

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

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:

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.

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.

Does that make sense?

We are now using ADS as an RDB essentially.

More like an Object Oriented Database actually.

Emmanuel Lecharny wrote:
> Interesting point. the problem is that when you modify an entry, you 
> do it by grabbing the entire entry from the disk (or from the cache, 
> but this is the same problem if the entry is not cached).
Yes - So if objects were broken down into individual attributes we could 
let the DAS reconstitute the object from the attributes.

Then when the update is written, the DAS would only need to send the 
updated attributes.

> Changing an object is done through a ModRequest operation, in which 
> you give the list of modified attributes. If the entry is not too big 
> (I mean, no JpegPhoto in it), then it's likely to be less than 1kbytes 
> to read from the disk. Reading 500 bytes compared to read 1kbytes 
> makes no difference, as the underlying system will read some 4Kbytes 
> block (let's assume it's 4Kbytes, even if it's not the real size in 
> your system). At this point, oprtimizing the server to read only the 
> modified attributes will not bring enormous gain, if any, but for sure 
> will add some complexity.
> However, if we switch to another backend (ie RDBMS), this might be 
> something to consider, as we may have to read attributes spreaded all 
> over a big table. I don't know exactly what would be the pros and cons 
> right now, but as teh RDBMS backend is not written (and we are still 
> considering implementing it), this is perfect timing to push new ideas.
> Emmanuel

So this is silly - but just for example:
Imagine imagine a Terabyte of addresses stored in ADS.

We wanted to process all the zips to add the new 4 digit extension at 
the end,
so mine would go from



So I only really wish to update the zip attribute of Address SDO object,
and the SDO change summary has the capability to enable this, but
if we store the entire object on ADS, then we have to write the entire 
thing back,
instead of just the changed zip.

So if we were writing to a database, we would just update the zip field 
of the database table.
This is also possible with ADS, but we need to generate and store the 
ObjectClass for the
address (or could be FooBoo Class, just some random class that we wish 
to store).


- Ole

> On 3/21/07, *Ole Ersoy* < 
> <>> wrote:
>     Hey Guys,
>     Just wanted to see if anyone had any thoughts on handling updates
>     to Java beans (Service Data Objects - but basically the same thing)
>     persisted with ADS.
>     With Service Data Objects we create a datagraph that is then
>     disconnected
>     from it's persistence source and we can mutate it.  Then later we
>     want to
>     persist the graph.  Each object in the graph has a change summary,
>     that
>     stores the fields that were updated.
>     This makes it possible to only update objects that have been
>     changed, and
>     we only need to update the fields that were changed.
>     However, I think the DirContext will overwrite the entire
>     object during the bind operation, rather than updating specific fields
>     on the object.
>     Initially I  was thinking that the object's attributes (primitive
>     properties - not references to other objects)
>     would be serialized and made into directory attributes.  But I think a
>     LDAP ObjectClass schema that corresponds to the
>     object's class (The class of the object we are persisting) would
>     have to
>     be generated and stored along with the instance.
>     This might lead to performance improvments, if doable...?
>     Thoughts?
>     Thanks,
>     - Ole
> -- 
> Cordialement,
> Emmanuel L├ęcharny
> <> 

View raw message