jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject Re: [jr3] Use JCache JSR-107 for (all) caches
Date Mon, 22 Feb 2010 22:45:48 GMT

On 19 Feb 2010, at 15:21, Marcel Reutegger wrote:

> On Thu, Feb 18, 2010 at 13:55, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>> Agreed. Ideally (not sure if that's feasible) we'd push all caching
>> down below the unified persistence layer.
> IMO that's exactly where a distributed cache belongs to.
> the current design already implements some aspects but lacks other
> important things. currently each cluster node has it's own bundlecache
> with invalidation triggered on external changes. but filling the cache
> is always done through shared storage. I think this can become a
> bottleneck when the number of cluster nodes is more than just a few.
> e.g. consider that each of the cluster nodes has event listener
> registered that are interested in current changes. this will cause a
> rush on the shared storage whenever a change is done. ideally the
> cluster nodes (or more specifically the micro-kernels) would share
> their cached items with other cluster nodes. shared storage is only
> accessed when none of the cluster nodes can provide the request
> version of an item.

Although distributed caches appear like a fix all solution replicated, and to some extents
invalidated caches always seem to choke on traffic levels when a cache really starts to matter.
Having used ehcache (which is good as a cache impl with jmx) reasonably extensively some observations.

Under the Cache layer (as opposed to a layer that knows something about the app)

  Replication is best totally avoided as a way of making a cluster scale to more than a few
  Invalidation can be effective, provide its not used to trigger reload and the invalidation
traffic isn't massive.

Over in Shindig, there is a simple Cache API with memcached and ehcache default implementations.
Most deployers tune those or replace with their own local implementations, putting cluster
wide code below the Cache API and above the cache implementation.

Putting the cache below the persistence api, or using a cache API would, IMHO address most
of these issue.

BTW, JSR-107 looks rather dead, and I found it lacking is certain areas.

> regards
> marcel

View raw message