On Sun, Sep 8, 2013 at 1:38 PM, Emmanuel Lécharny <[email protected]>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 ? > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > > -- Kiran Ayyagari http://keydap.com
