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

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

On 3/21/07, Ole Ersoy <[EMAIL PROTECTED]> 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
www.iktek.com

Reply via email to