When and how to use hibernate second level cache?

• the 2nd level cache is a key-value store. It only works if you get your entities by id
• the 2nd level cache is invalidated / updated per entity when an entity is updated/deleted via hibernate. It is not invalidated if the database is updated in a different way.
• for queries (e.g. list of customers) use the query cache.

In reality it is useful to have a key-value distributed cache - that's what memcached is, and it powers facebook, twitter and many more. But if you don't have lookups by id, then it won't be very useful.

First of all, let's talk about process level cache (or 2nd level cache as they call it in Hibernate). To make it work, you should

1. configure cache provider
2. tell hibernate what entities to cache (right in hbm.xml file if you use this kind of mapping).

You tell to the cache provider how many objects it should store and when/why they should be invalidated. So let's say you have a Book and an Author entities, each time you're getting them from the DB, only those that are not in cache will be selected from actually DB. This increases performance significantly. It's useful when:

• You write to the database only via Hibernate (because it needs a way to know when to change or invalidate entities in the cache)
• You read objects often
• You have a single node, and you don't have replication. Otherwise you'll need to replicate the cache itself (use distributed caches like JGroups) which adds more complexity, and it doesn't scale as good as share-nothing apps.

So when does cache work?

• When you session.get() or session.load() the object that was previously selected and resides in cache. Cache is a storage where ID is the key and the properties are the values. So only when there is a possibility to search by ID you could eliminate hitting the DB.
• When your associations are lazy-loaded (or eager-loaded with selects instead of joins)

But it doesn't work when:

• If you don't select by ID. Again - 2nd level cache stores a map of entities' IDs to other properties (it doesn't actually store objects, but the data itself), so if your lookup looks like this: from Authors where name = :name, then you don't hit cache.
• When you use HQL (even if you use where id = ?).
• If in your mapping you set fetch="join", this means that to load associations joins will be used everywhere instead of separate select statements. Process level cache works on children objects only if fetch="select" is used.
• Even if you have fetch="select" but then in HQL you use joins to select associations - those joins will be issued right away and they will overwrite whatever you specified in hbm.xml or annotations.

Now, about Query Cache. You should note that it's not a separate cache, it's an addition to the process level cache. Let's say you have a Country entity. It's static, so you know that each time there will be the same result set when you say from Country. This is a perfect candidate for query cache, it will store a list of IDs in itself and when you next time select all countries, it will return this list to the process level cache and the latter, in turn, will return objects for each ID as these objects are stored already in the 2nd level cache. Query cache is invalidated each time anything related to the entity changes. So let's say you configured from Authors to be placed into a Query Cache. It won't be effective as Author changes often. So you should use Query Cache only for more or less static data.