Concurrency Strategies for Hibernate Caching

Caching and concurrency management are tricky. If you have a cache that lives in memory but you have updates to the database that the objects originally came from, how are you going to make sure that the cached objects still reflect the contents of the database?

This really depends on what type of data you are dealing with. Data types that are mostly read (news, notices, articles) probably benefit from whatever caching you can provide, while areas of data that change a lot (shopping carts, server status records) probably won’t benefit from caching at all.

Here are the concurrency strategies on hibernate caching explained:

technorati tags:

  • Transactional: Full Transaction Isolation, even repeatable-read. This is not particularly fast, but it does guarantee full transactional isolation.
  • Read-Write: A bit more relaxed than transactional, it uses a timestamp to maintain Read-Commited transaction isolation.
  • Non-Strict Read-Write: With this one, you start ending up with stale data, because since it is not strict it provides no guarantee of consistency. If you think things may be updated and provide you with stale data, set a short timeout for expiration.
  • Read-Only: Use this one for Reference data that never changes (days of months, cities, states, etc).

Note that, on hibernate, the concurrency strategies available will depend on your cache provider. Also note that all caching only focuses on things your application updated. If you have other applications also updating data on the same database consider not using caching at all for those classes.

If you insist on using caching in this situation, be prepared for caching errors on production and be ready to do some cache management – provide a way to look into the cache statistics and clear the cached elements, and use timeouts that are sensible.

Finally, caching should be your last option for performance, not your first. I can’t tell you how many times I’ve seen teams want to mess around with the cache settings when they have queries so bloated that would make Windows Vista blush. Fix your query issues first, then apply caching. If you add caching when you haven’t fixed underlying query problems you only accomplish two things: Sweeping your problem under the rug (but you can still see the bump), and cause OutOfMemory errors.

Category: Best Practices