On Wed, May 28, 2008 at 9:49 PM, Emmanuel Lecharny <elecharny@apache.org> wrote:

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.