Thanks for the explanation Andrus. Good to get some insight in the tradeoffs involved. In our
project we are looking at distributed invalidation as well so great to hear cache groups are so
efficient.
It would be great to consolidate shared and local query caches though. That will reduce the surface
area of the problem space a bit. Not sure if such a change would be feasible however.
Kind regards
Bob
On 10/06/2010 16:25, Andrus Adamchik wrote:
> I would imagine cache groups will still be in the picture. I can't think
> of a scaleable cache management API without them. And yes, they do
> require planning in advanced cases.
>
> I am personally using distributed invalidation of cache groups when
> certain objects are changed. This allows to create custom business rules
> for partial and targeted cache invalidation with almost no performance
> overhead (e.g. if (object.createdDate < X) { expire
> "old_cache_for_entity_x_group" } else { expire
> "new_cache_for_entity_x_group" }. Pretty flexible, but does require
> upfront planning.
>
> I am still unsure how to reconcile object and query cache at this point.
> My current direction with that is to place both object and query cache
> under the same cache storage and management mechanism. But I can't see
> how we can do automatic invalidation of the right query cache groups
> efficiently, as any given object change may result in object removal
> from some lists (when its properties no longer match list fetch
> conditions) or addition to some others, etc., etc. In fact cache groups
> mechanism was the answer to the inability to predict how an arbitrary
> object change affects the cache.
>
> If there are better ideas, I'll be happy to hear them.
>
> Andrus
>
> On Jun 9, 2010, at 9:39 PM, Bob Schellink wrote:
>> Hi all,
>>
>> In the cache docs[1] it mentions there are plans to consolidate the
>> query and object caches at some
>> stage. If that happens, would cache groups still be necessary?
>>
>> While I find cache groups flexible, it requires quite a bit of
>> planning and manual configuration to
>> implement successfully. The problem is further compounded by the
>> different caches - local vs shared
>> and object vs query. We've been bitten a number of times where the
>> query cache isn't cleared when
>> updating objects.
>>
>> Is my assumption correct that if object and query cache is
>> consolidated, Cayenne would be able to
>> automatically clear the query cache if an object has changed?
>>
>> Kind regards
>>
>> Bob
>>
>> [1]: http://cayenne.apache.org/doc/caching-and-fresh-data.html
>>
>
>
This archive was generated by hypermail 2.0.0 : Thu Jun 10 2010 - 10:48:11 UTC