The Second Level Cache in Hibernate : Settings and Configurations.

A Hibernate Session is a transaction-level cache of persistent data. We can configure a cluster or JVM-level (SessionFactory-level) cache on a class-by-class and collection-by-collection basis. We can also plug in a clustered cache into Hibernate. At the time of providing cache we need to understand that when we are updating the persistence DB it will not automatically reflect on Cache.

Configuring CACHE in Hibernate

We need to tell Hibernate that which caching implementation we need to  use. This we can accomplish by specifying the name of a class that implements org.hibernate.cache.CacheProvider using the property hibernate.cache.provider_class. Hibernate comes bundled with a number of built-in integrations with open-source cache providers; additionally, we could implement your own and plug it in as outlined above. Prior to 3.2 Hibernate is defaulted to use EhCache as the default cache provider.

To find the CACHE PROVIDERS please check this post <Click Here>

Cache mappings

The <cache> element of a class or collection mapping has the following form:

<cache 
    usage="transactional|read-write|nonstrict-read-write|read-only"  (1)
    region="RegionName"                                              (2)
    include="all|non-lazy"                                           (3)
/>

(1)

usage (required) specifies the caching strategy: transactional, read-write, nonstrict-read-write or read-only

(2)

region (optional, defaults to the class or collection role name) specifies the name of the second level cache region

(3)

include (optional, defaults to all) non-lazy specifies that properties of the entity mapped with lazy="true" may not be cached when attribute-level lazy fetching is enabled

Strategy: read only
  • Useful for data that is read frequently but never updated.
  • It is Simple .
  • Best performer among the all.

If application needs to read but never modify instances of a persistent class, 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>
Strategy: read/write
  • Used when our data needs to be updated.
  • It’s having more overhead than read-only caches.
  • When Session.close() or Session.disconnect() is called the transaction should be completed in an environment where JTA is no used.
  • It is never used if serializable transaction isolation level is required.
  • In a JTA environment, for obtaining the JTA TransactionManager we must specify the propertyhibernate.transaction.manager_lookup_class.
  • To use it in a cluster the cache implementation must support locking.

If the application needs to update data, a read-write cache might be appropriate. This cache strategy should never be used if serializable transaction isolation level is required. If the cache is used in a JTA environment, you must specify the property hibernate.transaction.manager_lookup_class, naming a strategy for obtaining the JTA TransactionManager. In other environments, you should ensure that the transaction is completed when Session.close() or Session.disconnect() is called. If you wish to use this strategy in a cluster, you should ensure that the underlying cache implementation supports locking. The built-in cache providers do not.

<class name="eg.Cat" .... >
    <cache usage="read-write"/>
    ....
    <set name="kittens" ... >
        <cache usage="read-write"/>
        ....
    </set>
</class>
 
Strategy: nonstrict read/write
  • Needed if the application needs to update data rarely.
  • we must specify hibernate.transaction.manager_lookup_class to use this in a JTA environment .
  • The transaction is completed when Session.close() or Session.disconnect() is called In other environments (except JTA) .

If the application only occasionally needs to update data (ie. if it is extremely unlikely that two transactions would try to update the same item simultaneously) and strict transaction isolation is not required, a nonstrict-read-write cache might be appropriate. If the cache is used in a JTA environment, you 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.

Strategy: transactional
  • It supports only transactional cache providers such as JBoss TreeCache.
  • only used in JTA environment.

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 you must specify hibernate.transaction.manager_lookup_class.

Advertisements

List of Cache Providers in Hibernate and their Concurrency Support details

Here in this port you can find the list of Cache providers and their Concurrency support details. (Exerted from Official Hibernate Tutorial)

EHCache (Easy Hibernate Cache)
(org.hibernate.cache.EhCacheProvider)
  • It is fast.
  • lightweight.
  • Easy-to-use.
  • Supports read-only and read/write caching.
  • Supports memory-based and disk-based caching.
  • Does not support clustering.
OSCache (Open Symphony Cache)
(org.hibernate.cache.OSCacheProvider)
  • It is a powerful .
  • flexible package
  • supports read-only and read/write caching.
  • Supports memory- based and disk-based caching.
  • Provides basic support for clustering via either JavaGroups or JMS.
SwarmCache (org.hibernate.cache.SwarmCacheProvider)
  • is a cluster-based caching.
  • supports read-only or nonstrict read/write caching .
  • appropriate for applications those have more read operations than write operations.
JBoss TreeCache (org.hibernate.cache.TreeCacheProvider)
  • is a powerful replicated and transactional cache.
  • useful when we need a true transaction-capable caching architecture .

Cache providers.

Cache

Provider class

Type

Cluster Safe

Query Cache Supported

Hashtable (not intended for production use)

org.hibernate.cache.

HashtableCache

Provider

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)

yes (clustered invalidation)

yes (clock sync req.)

JBoss Cache 1.x

org.hibernate.cache.

TreeCacheProvider

clustered (ip multicast), transactional

yes (replication)

yes (clock sync req.)

JBoss Cache 2

org.hibernate.cache.

jbc2.JBossCache

RegionFactory

clustered (ip multicast), transactional

yes (replication or invalidation)

yes (clock sync req.)

Cache Concurrency Strategy Support

Cache

read-only

nonstrict-read-write

read-write

transactional

Hashtable (not intended for production use)

yes

yes

yes

 

EHCache

yes

yes

yes

 

OSCache

yes

yes

yes

 

SwarmCache

yes

yes

   

JBoss Cache 1.x

yes

   

yes

JBoss Cache 2

yes

   

yes