jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bart van der Schans <b.vandersch...@onehippo.com>
Subject Re: [jr3] Use JCache JSR-107 for (all) caches
Date Fri, 19 Feb 2010 10:26:41 GMT
Hi Stefan,

On Thu, Feb 18, 2010 at 11:00 AM, Stefan Guggisberg
<stefan.guggisberg@gmail.com> wrote:
> hi bart,
> On Wed, Feb 17, 2010 at 11:29 PM, Bart van der Schans
> <b.vanderschans@onehippo.com> wrote:
>> Hi,
>> Right now there are several "homegrown" caches in Jackrabbit. Some
>> configurable, some based on soft/weak references. Using JCache it
>> would make it possible to leverage existing caching implementations.
> jcache and friends have been suggested a number of times before.
Yes, I know. To me that indicates that maybe more people would like to
see a change in this area ;-)

> i had a look at jcache, ecache etc quite while ago, they didn't fit the
> the needs of jackrabbit core. the 'homegrown' caches in the core
> are not simple caches (holding serializable objects), the have special
> semantics and are fundamental to jackrabbit's implementation of
> isolation levels. none of the caching framworks i looked at supported
> the required semantics.
I agree that not all (most?) of jackrabbits current caches would
benefit (if even possible) to move to a general purpose cache. But for
example the BundleCache would be a good candidate.

> general purpose caching frameworks are probably fine at an application
> level, at the core level i'd rather rely on custom implementations that
> exactly do what we need, nothing more and nothing less.
> the core should IMO be small and higly optimized, not bloated with
> general purpose frameworks/black boxes ;)
I agree totally. The core could contain it's own simple default
implementation, but it could be nice if you could swap it for another
more bloated solution if that's what you require.

A lot would of course depend on how the new architecture is going to
be. If there aren't any caches, like Jukka mentioned to let the
persistence handle the caching, then there's of course no need to look
at generalized caches. But is we do need an equivalent of the current
BundleCache we should at least (re)consider making the caching
implementation pluggable.


> cheers
> stefan
>> This could help in making the caches better configurable and tunable
>> and have features like overflow to disk, which could help with large
>> transactions, persist caches to disk during restart for cache warming
>> and clustered caches. For example it could be interesting to share
>> bundle/item state caches between cluster nodes.
>> Regards,
>> Bart

Hippo B.V.  -  Amsterdam
Oosteinde 11, 1017 WT, Amsterdam, +31(0)20-5224466

Hippo USA Inc.  -  San Francisco
101 H Street, Suite Q, Petaluma CA, 94952-3329, +1 (707) 773-4646
http://www.onehippo.com   -  info@onehippo.com

View raw message