cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: [jira] [Commented] (CAY-1595) EHCache implementation of Provider<QueryCache>
Date Wed, 27 Jul 2011 20:16:38 GMT

On Jul 27, 2011, at 6:49 PM, Dzmitry Kazimirchyk (JIRA) wrote:

> 
> There may be some difficulties with this because EHCache unlike OSCache doesn't have
support for cache groups which Cayenne actively uses. As I've searched this is a major problem
for all users migrating from OSCache to EHCache and EHCache even has Jira for it: https://jira.terracotta.org/jira/browse/EHC-240
.

Oops. Now I am starting to remember why we picked OSCache against EHCache for Cayenne in the
first place... Yeah, seems like OSCache is unique in respect to "cache groups" feature. 

After a quick repeat look at EhCache after many years, it is definitely pretty advanced (I
am surprised it doesn't support groups considering everything else it supports) and I see
a bunch of things that I like. E.g. multiple caches per CacheManager allows to split cache
into regions which seems suitable to serve for unified cache approach between object and query
caches (something that's been on the list for some time). And IIRC this is how Hibernate does
it. 

Besides with some tweaking it allows to emulate a few OSCache behaviors I am used to. E.g.
cluster cache replication is done by copy by default, but it can be configured to be done
via a much lighter invalidation mechanism (trading consistency for performance - something
I am willing to do in the apps I am mostly dealing with).

> The question is should we wait for EHCache to implement cache groups or write our custom
solution for this? (or maybe something else)

Good question... From the Jira history, this issue has been shifted around for 2 years by
Terracotta, so it is hard to tell when it becomes standard. 

I suspect a custom implementation will be either complex, requiring a rewrite of big parts
of EhCache, or inefficient (such as our own MapQueryCache that scans the entire cache to remove
all items belonging to a group. I guess we can inspect the user patches and make a decision
on that. 

I think we can start with an implementation that quietly ignores groups and uses a single
cache (and hence a single expiration policy) for all query entries. It is rather crippled,
as it would preclude targeted invalidation, but it will be a start. And then who knows, maybe
EHC-240 is committed.

Andrus

P.S. Also after joining Terracotta, EhCache became sneaky spyware: http://adammonsen.com/post/512
Big surprise :-/


Mime
View raw message