Comments on: Hibernate Query (Lack Of) Caching

By: Bernard

Bernard — Tue, 27 Jan 2009 13:14:08 +0000

No worries. Interesting discussion anyway. As I have an heavy loaded application that somehow relies on cache to improve performance, your article raised a big fear in me. It made reread the part in JPA with Hibernate on query cache (chapter 15). This confirmed that my implementation was ok.
I am a regular reader of your blog and enjoying it. I usually don’t write comments but this time I thought your initial post needed clarification.
Cheers,
Bernard.

By: Robert

Robert — Tue, 27 Jan 2009 10:31:06 +0000

Granted, Bernard. I merely threw those out as options. Probably the only suggestion I made above that was serious was the option of making the queries themselves more tolerable of staleness – that is, to take something like the StaleTolerantQueryCache suggested above, and build it into Hibernate directly (including an option to defer to the caching system itself on how stale something can be).

For an alternative that is inline with the Hibernate philosophy, the event mechanism could be leveraged to allow vetoing of query cache evictions, even if the default Hibernate configuration never vetoed.

I own “Hibernate In Action”; I’ve read “Java Persistence with Hibernate”. Neither really covers query caching properly, from memory (my books are at work; I’m at home). According to the online table-of-contents, HIA gives 1 page, and JPwH gives 3-4.

In any case, this article isn’t an attack on Hibernate, or even a set of suggestions of what Hibernate could do differently. I stopped trying to do that (shortly after I started trying) when a discussion with Gavin King resulted in him saying “well, I’ll get the (EJB 3 persistence) spec changed then”. I use Hibernate, I recommend Hibernate, I think it’s a good tool, and I even enjoy pushing its limits and trying to work more inline with how it wants to work. But it’s not perfect, and when I come across limitations, I make a note here as an aide-mémoire. Nor do I pick on just Hibernate – lots of tools that I use get this treatment.

By: Bernard

Bernard — Tue, 27 Jan 2009 09:23:55 +0000

Hibernate already monitors changes to entities. Your sentences “it could monitor those to see if they still match” and “Updates to non-matching entities could be evaluated against cached queries to see if they should be inserted.” would be VERY VERY difficult to implement and would drive hibernate to take over the responsibility of the database itself. If you know Hibernate, you should be aware that it never does that, it’s not in its philosophy.
It’s true that Hibernate documentation, although good, is sometimes shallow on some aspects. In order to do efficient Hibernate development you really need a good Hibernate book on your side like ‘Hibernate in action’ or ‘Java Persistence with Hibernate’.

By: Robert

Robert — Sat, 24 Jan 2009 01:11:20 +0000

Bernard, how does Hibernate know if an update in the database occurs? It can’t. Therefore, for entity caching, Hibernate provides numerous cache modes for entities, where as a developer we can choose to trade off performance vs. staleness. Query caches could have the same. They don’t.

So one option would be to configure stale-tolerant vs. non-stale tolerant directly into the query cache.

Another alternative would be to monitor changes to entities. Hibernate knows which entities were returned in a query; it could monitor those to see if they still match. Updates to non-matching entities could be evaluated against cached queries to see if they should be inserted. (Both as configurable options; the former is more efficient than the latter)

So there are a number of options.

The Hibernate documentation also provides detailed breakdowns of how the entity caches works. There’s just a brief description of how to configure query and collection caching, but with no explanation of the implications (as mentioned above).

By: Bernard

Bernard — Fri, 23 Jan 2009 10:14:55 +0000

This kind of behavior from Hibernate makes perfect sense to me. How would Hibernate know when an update occurs on one entity that it doesn’t affect the cached query results. The implementation in Hibernate is generic and is designed to work correctly in all type of applications. Like you wrote in the conclusion of your article, if you need a different behavior you need to implement your own cache mechanism on top of Hibernate.

By: Jonah S

Jonah S — Fri, 22 Feb 2008 10:37:52 +0000

Try implementing a StaleTolerantQueryCache as described here: http://www.hibernate.org/213.html

By: Bruno da Silva

Bruno da Silva — Sat, 16 Feb 2008 05:44:17 +0000

I would suggest you to remove cache from your collections and relations and put all lazy true and test because if your cache is getting evicted the load/fetch process is much faster..much faster in collection without cache defined.

or i didn’t test yet … put the cache read-only and implement by your self the eviction policy .. i never tested a cache read-only on a modifiable entity yet..

By: Daniel Serodio

Daniel Serodio — Fri, 15 Feb 2008 22:50:08 +0000

I noticed that Hibernate’s cache is much less effective than I thought, but I hadn’t dug deep enough to come to these conclusions. Isn’t there a way to make Hibernate’s cache more effective instead of creating a separate cache layer above it?