Hi Stefan,
On Thu, Feb 18, 2010 at 11:00 AM, Stefan Guggisberg <[email protected]> wrote: > hi bart, > > On Wed, Feb 17, 2010 at 11:29 PM, Bart van der Schans > <[email protected]> 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. Regards, Bart > > 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 - [email protected] -----------------------------------------------------------------
