On Sun, Sep 8, 2013 at 1:38 PM, Emmanuel Lécharny <elecharny@gmail.com> wrote:
Hi guys,

we need to use a cache in the partitions, for entries, aliases, and also
for whatever cache the partitins could need (assuming that this can be
configurable : for instance, JDBM has its own cache, but Mavibot does not).

This cache could be handled by the CacheService, which is created in the
ApacheDsService, the DefaultDirectoryServiceFactory, or in the
DefautDirectoryService if it's not injected in this class.

AbstractBTreePatition alady has support for entry cache and likewise Index implementations as well
have support for storing the tuples in the cache 
On a side note, the CacheService is a wrapper on top of EhCache, which
is, IMO, not good enough : it should be an interface, with some factory
which creates various instances of CacheService instances, one of them
being based on EhCache. In case we wan't to use another cache later, or
design our own, then we would just instanciate the correct CacheService
instance using the factory.
+0 IMHO, I don't see any gain in this, _very_ few might go to this extent of changing the cache

That being said, I thing the CacheService should be propagated down to
the partitions for them to be used - or not.

this is alreay the case
The CacheService should also be configurable through the LDIF
configuration file - we don't necessarily need to make the CacheService
a fully configured system, because then we would face a chicken/egg pb :
how do we read the configuration if we can't configure the cacheService,
which will be used by the LdifPartition ?

one aspect that is present in the cache service is it copies the cache configuration
file to the config folder (not sure if this code is still present, but it was present before)
Those are elements to think about, because they are pretty critical from
the performance POV. However, this is by no mean urgent : this won't fix
a bug, it will just make the server to run faster.

I suggest we focus on decoupling the cacheService we have from it's
EhCache implementation atm, so that the API is not to be odified after
the next release, and that's it. I also suggest to make this
CacheService available in the Partitions, even if it's not used.

again, IMO plugging in this kind of mechanism may not be of great help, just more work
on a feature that may never be used, I believe Ehcache is the best available cache with
the compatible license and unless we try to write our own we don't need this new feature
Thoughts ?

Emmanuel Lécharny

Kiran Ayyagari