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
