JPA 2.0 Cache Vs. Hibernate Cache: Differences in Approach
Pros, Cons and Best Uses of JPA Level 2 Cache
Here are the pros and cons of JPA Level 2 cache:
- Avoids database access for already loaded entities
- Faster for reading frequently accessed unmodified entities
- Memory consumption for large amount of objects
- Stale data for updated objects
- Concurrency for write (optimistic lock exception or pessimistic lock)
- Bad scalability for frequent or concurrently updated entities
Level 2 cache is best used for entities that are frequently read, infrequently modified, and not critical if stale. You can use the query cache technique to cache queries that are executed often with the same parameters for tables that are rarely modified.
Caching in Hibernate
Hibernate uses first-level cache by default to store the objects for every transaction. Hibernate's second-level cache, which is supported by the
SessionFactory, enables the objects to be accessed at the application level, thereby reducing the number of database transactions required for accessing an object. Hibernate achieves caching by storing the individual property values of the instance rather than storing the objects themselves.
Hibernate 3.0 supports the following four open source caching implementations for second-level cache:
- EHCache (
org.hibernate.cache.EhCacheProvider) -- Default
- OSCache (
- SwarmCache (
- JBoss TreeCache (
The second-level cache can be enabled or disabled by setting the property
hibernate.cache.use_second_level_cache to true (the default for classes that specify
<cache> mapping) or false, respectively. Here is a true setting:
You can choose which implementation to use for an application by setting the
hibernate.cache.provider_class property in the
hibernate.cfg.xml file as follows.
You also can enable caching at the class level or the collection level by setting the
<cache> element in the mapping file as follows:
<cache usage="read-only" region="regionName" include="all"/>
Here's a breakdown of the elements in the above code:
Usagespecifies the caching strategy and can take other values such as
Regionis an optional attribute that specifies the second-level cache region. By default it is the name of the class/collection.
Includeis an optional attribute that takes the
allvalue by default. If the value
non-lazyis set to include then entities having
lazy=truecannot be cached.
You can also enable caching by setting the
<collection-cache> elements in the
hibernate.cfg.xml file, after which you would configure the cache rule for classes for which you want cache to be enabled in a separate EhCache configuration file (
ehcache.xml) and place it in the root directory of the project.
You can also cache queries that are executed very frequently with the same set of parameters by using query cache. Query cache is set to false by default and you can enable it by adding the following property in the
This query adds
UpdateTimestampsCache regions, which hold the query cached results and the time stamps of the most recent update to the table, respectively. The query results can be cached for a particular query by calling
setCacheable(true) on the query instance.
Hibernate 3.5 Caching
The Hibernate caching strategies remain the same in version 3.5, but certain additional cache providers such as JBoss Cache 2, JBoss Cache 1.x (part of Hibernate 3.2) and Hashtable (not for production) have been added.
The other major advancement in Hibernate 3.5 is the addition of Infinispan as another standard for second-level cache. Infinispan is an open source, scalable data grid platform that exposes a JCache (JSR-107)-compatible cache interface. Infinispan provides a much higher degree of concurrency because it uses a specialized data structure, provides a massive heap capability and is not tied just to Java. It also supports PHP, Python, Ruby etc.
In this article we compared caching in JPA 2.0 with the caching in Hibernate. By introducing new caching features and promoting standardization, JPA 2.0 has made many tasks easier for developers. However, Hibernate is far ahead in many aspects because all its features have been supported for much longer.
The authors would like to sincerely thank Mr. Subrahmanya SV (VP, ECOM Research Group, E&R) for his ideas, guidance, support and constant encouragement and Ms. Mahalakshmi for kindly reviewing this article and providing valuable comments.
About the Authors
Sangeetha S. works as a Senior Technical Architect at the E-Commerce Research Labs at Infosys Technologies. She has over 10 years of experience in design and development of Java and Java EE applications. She has co-authored a book on 'J2EE Architecture' and also has written articles for online Java publications.
Nitin KL works at the E-Commerce Research Labs at Infosys Technologies. He is involved in design and development of Java EE applications using Hibernate, iBATIS, and JPA.
Page 2 of 2