cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcin Skladaniec <>
Subject Re: caching documentation
Date Wed, 05 Mar 2008 12:37:28 GMT
Thank you very much for the reply, I need to read through one more  
time and I'll try to make use of it as well as write some  
documentation down for the website.


On 05/03/2008, at 9:20 PM, Andrus Adamchik wrote:

> On Mar 4, 2008, at 1:26 AM, Marcin Skladaniec wrote:
>> Hi
>> The documentation on caching (

>>  and isn't very  
>> comprehensive,
> Agreed. There are lots of new features related to caching in 3.0,  
> and we do not communicate them well to the users as of yet.
>> it does not answer questions like:
>> - what is actually stored in cache pks? datarows ? objectIds ?
> There are two types of cache: object cache [1] and query cache.
> * Object cache (stored at ObjectContext): Map<ObjectId, Persistent>  
> (it may not be declared as such, but this is what it is).
> * Object cache (stored at DataDomain... so really a snapshot cache):  
> Map<ObjectId, DataRow>
> * Query cache (stored at ObjectContext, aka LOCAL_CACHE):  
> Map<String, List<Persistent|DataRow>
> * Query cache (stored at DataDomain, aka SHARED_CACHE): Map<String,  
> List<DataRow>
>> - does caching change when paging is on ?
> Yes, there are some caveats, and a few things were tweaked recently.  
> LOCAL_CACHE works (both ROP and two tier). There is no SHARED_CACHE  
> support (and I want to make this more formal - throw an  
> IllegalStateException if pagination and SHARED_CACHE are used  
> together). One reason why I want to do that is that it appeared  
> under ROP as if SHARED_CACHE worked, when it fact things worked  
> differently, as a side effect of the special handling of paginated  
> lists on the ROP server (see below).
>> - does caching require special measures when used with ROP ?  
>> (meaning the propagation of changes between contexts)
> Not really, maybe an understanding of how it is implemented.  
> Paginated list is always cached in the *server* local cache,  
> regardless of the query cache settings. I.e. "LOCAL_CACHE +  
> paginated list + ROP" means caching on both server and client;  
> "NO_CACHE + paginated list + ROP" still means caching on the server.  
> This is done in order to avoid transferring unresolved ID's to the  
> client.
>> - how to properly use SelectQuery.setCacheGroups()?
> Cache groups are ignored unless you use advanced implementations of  
> QueryCache on the server (e.g. OSCache). RefreshQuery can also  
> target cache groups (see below). "cache group" is a mechanism to  
> allow backend code to perform smart cache invalidation without  
> knowing anything about the nature of the queries. E.g. you can have  
> two groups "objects_that_change_often" and  
> "objects_that_rarely_change", corresponding to 2 OSCache  
> invalidation rules, "once per minute" vs. "once per day"... Now when  
> you add new queries, you do not need to change configuration, if  
> they fall into one of the existing "groups"...
> So the trick with cache groups is to find common data invalidation  
> patterns in your app. Each repeating pattern becomes a group. This  
> is a logical task, with very little code involved.
>> what happens when a query has more than one cache group specified?
> Invalidation rules for all groups are combined. I rarely used that  
> in practice, but still think this allows some extra flexibility,  
> e.g. if the same query falls in a broad category and also in a very  
> specific one. E.g. "objects_that_rarely_change" and  
> "objects_that_change_when_event_X_occurs".
>> - how long the cache entries sit in the memory, is there a way to  
>> invalidate all cache from time to time ?
> Query cache (both shared and local): default mechanism is LRU and no  
> expiration. OSCache allows to configure size and advanced expiration  
> rules per cache group.
> Snapshot cache: LRU. Size configurable in the Modeler.
> Object cache (server): Unlimited size map with weak references.
>> - how to invalidate cache using RefreshQuery, the

>>  is just a list of suggestions on how it might work in the future.
> Yeah, this is not documented properly. I need to poke around a bit  
> more to provide accurate information on RefreshQuery behavior. It  
> was an early idea of cache handling, but I stopped using it in my  
> own apps, as OSCache works beautifully, supports clustering, etc.,  
> etc. And rather importantly - it removes cache management logic from  
> the code (i.e. explicit invalidation vs. configuration-based one).
>> Me and Ari are willing to document the caching feature, but we  
>> would need some help.
> Awesome! I'd imagine the trick here is to separate everything  
> discussed here into "internal-design-not-relevant-to-the-user" part  
> and "cache-user-guide" part to avoid confusing people and exposing  
> too many implementation details that will likely change over time.
> Andrus
> [1]

View raw message