Catching Introduction

While working with Hibernate web applications we will face so many problems in
its performance due to databasetraffic. 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 ourapplication and
the database will be reduced when the application want to access that data again.
Maximum theapplication 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 thedatabase. 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.
• <cache> element.
• 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 thenumber 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 entireapplication, 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 differentperformance, 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.

<class name="abc.mutable " mutable="true ">

<cache usage="read-only"/>
....
</class>
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 anenvironment 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.

Here is an example for using the read-write cache stringategy.

<class name="abc.xyz" .... >

<cache usage="read-write"/>
….
<set name="yuv" ... >
<cache usage="read-write"/>
….
</set>
</class>
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.

<class name="abc.xyz" .... >

<cache usage=" nonstringict-read-write"/>
….
</class>
3.4) Transactional

• It supports only transactional cache providers such as JBoss TreeCache.

• only used in JTA environment.

) Configuration

For configuring cache the hibernate.cfg.xml file is used. A typical configuration

file is shown below.

<hibernate-configuration>
<session-factory>
...
<property name="hibernate.cache.provider_class">
org.hibernate.cache.EHCacheProvider
</property>
...
</session-factory>
</hibernate-configuration>

The name in <property> tag must be hibernate.cache.provider_class for

activating second-level cache. We can
use hibernate.cache.use_second_level_cache property, which allows you
to activate and deactivate thesecond-level cache. By default, the second-level
cache is activated and uses the EHCache.

5) <cache> element

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

<cache
usage=" caching stringategy"
region="RegionName"
include="all | non-lazy"/>

• usage (mandatory) specifies the caching stringategy: transactional, read-

write, nonstringict-read-write or read-only.
• region (optional) specifies the name of the second level cache region .
• include (optional) non-lazy specifies that properties of the entity mapped
 with lazy="true" may not be cached when attribute-level lazy fetching is
enabled.

The <cache> element of a class is also called as the collection mapping.

6) Caching the queries

Until now we saw only caching the transactions. Now we are going to study about
the caching the queries.Suppose some queries are running frequently with same
set of parameters, those queries can be cached. We have to
sethibernate.cache.use_query_cache to true by
calling Query.setCacheable(true) for enabling the query cache. Actually updates in
the queries occur very often. So, for query caching, two cache regions are
necessary.

• For storing the results.( cache identifier values and results of value type only).
• For storing the most recent updates.

Query cache always used second-level cache only. Queries wont cached by
default. Here is an example implementation of query cache.

List xyz = abc.createQuery("Query")

.setEntity("…",….)
.setMaxResults(some integer)
.setCacheable(true)
.setCacheRegion("region name")
.list();

We can cache the exact results of a query by setting

the hibernate.cache.use_query_cache property in thehibernate.cfg.xml
file to true as follows:

<property name="hibernate.cache.use_query_cache">true</property>

Then, we can use the setCacheable() method on any query we wish to cache.

7) Custom Cache

To understand the relation between cache and the application the cache
implementation must generate statistics of cache usage.

7.1) Custom Cache Configuration

In the hibernate.properties file set the property hibernate.cache.provider_class

= examples.customCache.customCacheProvider.

7.2) Implementation :: ExampleCustomCache

Here is the implementation of ExampleCustomCache. Here it uses Hashtable for

storing the cache statistics.

package examples.ExampleCustomCache;

import net.sf.hibernate.cache;
import java.util;
import org.apache.commons.logging;

public class ExampleCustomCache implements Cache

{
public Log log = LogFactory.getLog(ExapleCustomCache.class);
public Map table = new Hashtable(100);
int hits, misses, newhits, newmisses, locks, unlocks, remhits,
remmisses, clears, destroys;

public void statCount(StringBuffer input, String string1, int value)

{
input.append(string1 + " " + value);
}

public String lStats()

{
StringBuffer res = new StringBuffer();

statCount(res, "hits", hits);

statCount(res, "misses", misses);
statCount(res, "new hits", newhits);
statCount(res, "new misses", newmisses);
statCount(res, "locks", lock);
statCount(res, "unlocks", unlock);
statCount(res, "rem hits ", remhits);
statCount(res, "rem misses", remmisses);
statCount(res, "clear", clears);
statCount(res, "destroy", destroys);

return res.toString();
}

public Object get(Object key)

{
if (table.get(key) == null)
{
log.info("get " + key.toString () + " missed");
misses++;
} else
{
log.info("get " + key.toString () + " hit");
hits++;
}

return table.get(key);
}

public void put(Object key, Object value)

 {
log.info("put " + key.toString ());
if (table.containsKey(key))
{
newhits++;
} else
{
newmisses++;
}
table.put(key, value);
}

public void remove(Object key)

{
log.info("remove " + key.toString ());
if (table.containsKey(key))
{
remhits++;
} else
{
remmisses++;
}
table.remove(key);
}

public void clear()

{
log.info("clear");
clears++;
table.clear();
}

public void destroy()

{
log.info("destringoy ");
destroys++;
}

public void lock(Object key)

{
log.info("lock " + key.toStringing());
locks++;
}

public void unlock(Object key)

{
log.info("unlock " + key.toStringing());
unlocks++;
}

Here is the example of Custom Cache.

Package examples.ExapleCustomCache;

import java.util;
import net.sf.hibernate.cache;

public class ExampleCustomCacheProvider implements CacheProvider

{

public Hashtable cacheList = new Hashtable();

public Hashtable getCacheList()

{
return cacheList;
}

public Stringing cacheInfo ()

{
StringingBuffer aa = new StringingBuffer();
Enumeration cList = cacheList.keys();

while (cList.hasMoreElements())
{
Stringing cName = cList.nextElement().toStringing();
aa.append(cName);

ExapleCustomCache myCache =
(ExapleCustomCache)cacheList.get(cName);

aa.append(myCache.lStats());
}

return aa.toStringing();
}

public ExampleCustomCacheProvider()
{
}

public Cache bCache(String string2, Properties properties)

{
ExampleCustomCache nC = new ExapleCustomCache();
cacheList.put(string2, nC);
return nC;
}

}
8) Something about Caching
8.1) Performance

Hibernate provides some metrics for measuring the performance of caching, which
are all described in the Statistics interface API, in three categories:

• Metrics related to the general Session usage.

• Metrics related to the entities, collections, queries, and cache as a whole.
• Detailed metrics related to a particular entity, collection, query or cache
region.

8.2) About Caching

 • All objects those are passed to methods save(),
update() or saveOrUpdate() or those you get from load(), get(), list(),
iterate() or scroll() will be saved into cache.
• flush() is used to synchronize the object with database and evict() is used to
delete it from cache.
• contains() used to find whether the object belongs to the cache or not.
• Session.clear() used to delete all objects from the cache .
• Suppose the query wants to force a refresh of its query cache region, we
should callQuery.setCacheMode(CacheMode.REFRESH).

9) Conclusion

Caching is good one and hibernate found a good way to implement it for improving
its performance in webapplications especially when more database traffic occurs. If
we implement it very correctly, we will get our applications to be running at
their maximum capacities. I will cover more about the caching implementations in
my coming articles. Try to get full coding guidelines before going to implement this.