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
