Cache improves performance by transparently storing data such that future requests for that data can be served faster. Hibernate offers a session scope transactional cache which spans the scope of the session. Hibernate also offers a configurable secondary level cache which spans across multiple sessions. Clustered/Distributed Caches can be configured so that it can be accessed across the entire application server cluster.
Hibernate secondary cache offers pretty good entity cache. Entity cache speeds up entity loading by its primary key. For instance:
select c from Cat c where c.id = :id
It supports query cache too, to enable query cache, you'll need to specify the hibernate property:
hibernate.cache.use_query_cache true
Query cache caches Query result sets, so the cache can provide you an answer for the queries like:
select p from Person p where p.sin = :sin
Let's say, the SIN of a person is never gonna change, so cache the above query will be useful.
Hibernate provides 'natural id' based on queries which can effectively solve the above problem. However, there are many other queries that hibernate cannot handle effectively. For instance, if we want to find all contact information (phone numbers only) for a person:
select pn from PhoneNumbers pn where pn.person.id = :pid
The primary problem for Query caches, is that hibernate will completely invalidated by any modification to the underlying table, even on entities that's totally unrelated to the query. In the above example, any insertion/update/deletion to the telephone table, on any record, will completely wipe out the entire cache for the above query.
There needs to be a 'smart query cache' to solve this problem. Fortunately, this can be done by providing custom query cache, and we can then refreshes them by listening on hibernate 'entity modification' events. The listener will allow us to intercept any insertion/update/deletion to any telephone record, and then we can determine to only refresh the affected query cache.
