On 10/06/2010 16:25, Andrus Adamchik wrote:
>
> 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.
I had some time reading up[1] on the approach Hibernate takes to caching. In short Hibernate has
automatic query cache invalidation BUT according to the article[1] it is not as effective as one
might expect and can have an inverse effect, making the application slower. Please note that I am
simply passing on this information, I haven't verified this myself.
Like Cayenne, Hibernate has both an Object and Query cache (there is also a Collection cache to
cache relationships). It also has a Timestamp cache that is used to automatically invalidate the
Query cache. I'll quote the relevant part from the article:
"The timestamp cache keeps track of the last update timestamp for each table (this timestamp is
updated for any table modification). If query caching is on, there is exactly one timestamp cache
and it is utilized by all query cache instances. Any time the query cache is checked for a query,
the timestamp cache is checked for all tables in the query. If the timestamp of the last update on a
table is greater than the time the query results were cached, then the entry is removed and the
lookup is a miss."
The problem with the Hibernate approach of 'automatic Query Cache invalidation' is that every time
the Timestamp cache is updated for a table, queries over that table must be refetched. This can lead
to many cache misses. The other problem (and reason why Hibernate Query Cache can have an inverse
effect) is that the Timestamp cache can become a new bottleneck for the application.
Quoting the article again:
"This cache has a single coarse lock that is locked for all inserts/updates/deletes to update the
timestamp of a table and also for every lookup that occurs through the query cache. Under load, this
lock can easily become a bottleneck."
In summary: Cayenne's approach of Cache Groups with manual invalidation seems more efficient and
useful compared to Hibernate.
Kind regards
Bob
[1]: http://tech.puredanger.com/2009/07/10/hibernate-query-cache/
This archive was generated by hypermail 2.0.0 : Sat Jul 10 2010 - 04:43:00 UTC