Hibernate Caching

Caching is a technique which prevents executing the same query into the database again and again. Using caching, output of a query is saved into a cache and when the same query is executed, it gets data from the cache rather than the database. This technique enhances the performance of the application.

There are two types of caching used in Hibernate

1. First Level Cache
2. Second Level Cache

First Level Cache

First level cache is maintained by session object. And it is enabled by default. First level cache data is available only for that session object. It will not be so for the entire application.

Second Level Cache

Second level cache is held by SessionFactory object. The data in this cache is available for the entire application. But it is not enabled by default. In stead, we have to enable it explicitly. There are many providers for second level cache. Below are few such names.

Cache	Provider class	Type	Query Cache Supported
Hashtable (not intended for production use)	org.hibernate.cache. HashtableCacheProvider	memory	yes
EHCache	org.hibernate.cache. EhCacheProvider	memory, disk	yes
OSCache	org.hibernate.cache. OSCacheProvider	memory, disk	yes
SwarmCache	org.hibernate.cache. SwarmCacheProvider	clustered (ip multicast)
JBoss Cache 1.x	org.hibernate.cache. TreeCacheProvider	clustered (ip multicast), transactional	yes (clock sync req.)
JBoss Cache 2	org.hibernate.cache.jbc2. JBossCacheRegionFactory	clustered (ip multicast), transactional	yes (clock sync req.)

Cache Strategies

1. Strategy: read only

If the application needs to read but never modify persistent class object, a read-only cache may be used. This is the simplest and best performing strategy. It’s even perfectly safe for use in a cluster.

<class name="eg.Immutable" mutable="false">
    <cache usage="read-only"/>
    ....
</class>

2. Strategy: read/write

If the application needs to read as well as update data, a read-write cache strategy is appropriate. This cache strategy should never be used if serializable transaction isolation level is required. If this strategy is to be used in a cluster, we should ensure that the underlying cache implementation supports locking. The built-in cache providers do not.

<class name="eg.Lion" .... >
    <cache usage="read-write"/>
    ....
    <set name="cubs" ... >
        <cache usage="read-write"/>
        ....
    </set>
</class>

3. Strategy: nonstrict read/write

If the application only occasionally needs to update data which means it is extremely unlikely that two transactions would try to update the same item at the same time and strict transaction isolation is not required, a nonstrict-read-write cache might be appropriate. In cases, the cache is used in a JTA environment, we must specify hibernate.transaction.manager_lookup_class. In other environments, you should ensure that the transaction is completed when Session.close() or Session.disconnect() is called.

4. Strategy: transactional

The transactional cache strategy provides support for fully transactional cache providers such as JBoss TreeCache. Such a cache may only be used in a JTA environment and we must specify hibernate.transaction.manager_lookup_class.