directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: Cache and partitions...
Date Mon, 09 Sep 2013 02:46:05 GMT
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 ?
>
> --
> Regards,
> Cordialement,
> Emmanuel L├ęcharny
> www.iktek.com
>
>


-- 
Kiran Ayyagari
http://keydap.com

Mime
View raw message