On Jul 27, 2011, at 11:16 PM, Andrus Adamchik wrote: > 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.
So here is an attempt of cache group design over EHCache... First, a few assumptions: 1. if a query has multiple cache groups, we ignore all but the first one. This is quite reasonable IMO. It will suffice for most scenarios. 2. We store keys for each cache group in a separate EHCache instance within the same CacheManager. 3. For entries with no cache groups, we allocate a separate EHCache instance. I think this will allow us to implement all methods of QueryCache interface. However we may end up with duplicate cache entries if the same query was run with different cache groups, which may potentially increase memory use and introduce a new type of cache consistency problems. So it is not as flexible as OSCache, but is much better than no cache group support at all. As long as users are aware of it, we should be fine. Andrus
