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 - 06:26:18 UTC