directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [perf] Should we really deep clone the serverEntry ?
Date Thu, 29 May 2008 05:21:07 GMT
On Wed, May 28, 2008 at 9:49 PM, Emmanuel Lecharny <>

> Hi,
> I just realize that it might not be a good idea to deep clone ServerEntry
> instances when searching data into the server.
> Currently, when we get an entry from the backend, we clone it in order to
> avoid modification of the cache (the entry might be - and hopefully is -
> cached) when removing attributes from it before returning it to the user
> (for instance when removing operational attributes, or selecting the
> attributes the user have asked for).
> But we never remove a value, or modify an attribute, unless another request
> modify the entry. So my question : what if we simply clone the ServerEntry,
> but not the attributes ? It will save a huge amount of processing (cloning
> attributes costs around 28% of the global time spent into the server).
> What if we add a lock mechanism (a monitor for instance) to protect entries
> in the cache from being modified while they are searched ? It could be as
> simple as a flag which will be set when the entry has been modified (a
> antomicBoolean could be just enough).
> Did I missed something ? Does it make sense ?

Hmmm search I think uses lookup for entries that are not pulled out of the
master table.  Basically searches are conducted on system indices (user
indices too if present).  The lower layers return IndexEntry objects which
contain index tuples.  If the object is to be returned or pulled to
calculate some assertion then it is set via IndexEntry.setObject().

Write operations also use lookup() operations.  So I think it might have
been a bad idea to use this ClonedServerEntry object perhaps.

Let me think about this one some more.  I need to look at it in depth a
little more.


View raw message