1) Introduction
While working with Hibernate web applications we will face so many problems in its performance due to database traffic. That to when the database traffic is very heavy . Actually hibernate is well used just because of its high performance only. So some techniques are necessary to maintain its performance. Caching is the best technique to solve this problem. In this article we will discuss about, how we can improve the performance of Hibernate web applications using caching.
The performance of Hibernate web applications is improved using caching by optimizing the database applications. The cache actually stores the data already loaded from the database, so that the traffic between our application and the database will be reduced when the application want to access that data again. Maximum the application will works with the data in the cache only. Whenever some another data is needed, the database will be accessed. Because the time needed to access the database is more when compared with the time needed to access the cache. So obviously the access time and traffic will be reduced between the application and the database. Here the cache stores only the data related to current running application. In order to do that, the cache must be cleared time to time whenever the applications are changing. Here are the contents.
* Introduction.
o First-level cache.
o Second-level cache.
* Cache Implementations.
o EHCache.
o OSCache.
o SwarmCache.
o JBoss TreeCache.
* Caching Stringategies.
o Read-only.
o Read-Write.
o Nonstriict read-write.
o Transactional.
* Configuration.
*
* Caching the queries.
* Custom Cache.
o Configuration.
o Implementation :: ExampleCustomCache.
* Something about Caching.
o Performance.
o About Caching.
* Conclusion.
Hibernate uses two different caches for objects: first-level cache and second-level cache..
1.1) First-level cache
First-level cache always Associates with the Session object. Hibernate uses this cache by default. Here, it processes one transaction after another one, means wont process one transaction many times. Mainly it reduces the number of SQL queries it needs to generate within a given transaction. That is instead of updating after every modification done in the transaction, it updates the transaction only at the end of the transaction.
1.2) Second-level cache
Second-level cache always associates with the Session Factory object. While running the transactions, in between it loads the objects at the Session Factory level, so that those objects will available to the entire application, don’t bounds to single user. Since the objects are already loaded in the cache, whenever an object is returned by the query, at that time no need to go for a database transaction. In this way the second level cache works. Here we can use query level cache also. Later we will discuss about it.
2) Cache Implementations
Hibernate supports four open-source cache implementations named EHCache (Easy Hibernate Cache), OSCache (Open Symphony Cache), Swarm Cache, and JBoss Tree Cache. Each cache has different performance, memory use, and configuration possibilities.
2.1) 2.1 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.
2.2)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.
2.3)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.
2.4)JBoss TreeCache (org.hibernate.cache.TreeCacheProvider)
* is a powerful replicated and transactional cache.
* useful when we need a true transaction-capable caching architecture .
3) Caching Stringategies
Important thing to remembered while studying this one is none of the cache providers support all of the cache concurrency strategies.
3.1) Read-only
* Useful for data that is read frequently but never updated.
* It is Simple .
* Best performer among the all.
Advantage if this one is, It is safe for using in a cluster. Here is an example for using the read-only cache strategy.
....
3.2) 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 property hibernate.transaction.manager_lookup_class.
* To use it in a cluster the cache implementation must support locking.
Here is an example for using the read-write cache stringategy.
….
….
3.3) 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) .
Here is an example for using the nonstrict read-write cache stringategy.
….
3.4) Transactional
* It supports only transactional cache providers such as JBoss TreeCache.
* only used in JTA environment.
Introduction to Hibernate Caching
