Level2 Caching In Hibernate

By -

Hibernate Caching

Hibernate uses two different caches for objects: first-level cache and second-level cache.
First-level cache is associated with the Session object, while second-level cache is associated with the Session Factory object. By default, Hibernate uses first-level cache on a per-transaction basis. Hibernate uses this cache mainly to reduce the number of SQL queries it needs to generate within a given transaction. For example, if an object is modified several times within the same transaction, Hibernate will generate only one SQL UPDATE statement at the end of the transaction, containing all the modifications. To reduce database traffic, second-level cache keeps loaded objects at the Session Factory level between transactions. These objects are available to the whole application, not just to the user running the query. This way, each time a query returns an object that is already loaded in the cache, one or more database transactions potentially are avoided.

In addition, you can use a query-level cache if you need to cache actual query results, rather than just persistent objects.

Cache Implementations
You have the option to tell Hibernate which caching implementation to use 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 (listed below);. Hibernate supports the following open-source cache implementations out-of-the-box:
  • EHCache (org.hibernate.cache.EhCacheProvider)
  • OSCache (org.hibernate.cache.OSCacheProvider)
  • SwarmCache (org.hibernate.cache.SwarmCacheProvider)
  • JBoss TreeCache ( org.hibernate.cache.TreeCacheProvider)

Each cache provides different capacities in terms of performance, memory use, and configuration possibilities:

  • EHCache is a fast, lightweight, and easy-to-use in-process cache. It supports read-only and read/write caching, and memory- and disk-based caching. However, it does not support clustering.
  • OSCache is another open-source caching solution. It is part of a larger package, which also provides caching functionalities for JSP pages or arbitrary objects. It is a powerful and flexible package, which, like EHCache, supports read-only and read/write caching, and memory- and disk-based caching. It also provides basic support for clustering via either JavaGroups or JMS.
  • SwarmCache is a simple cluster-based caching solution based on JavaGroups. It supports read-only or nonstrict read/write caching (the next section explains this term). This type of cache is appropriate for applications that typically have many more read operations than write operations.
  • JBoss TreeCache is a powerful replicated (synchronous or asynchronous) and transactional cache. Use this solution if you really need a true transaction-capable caching architecture.

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)

/>

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

  • region (optional, defaults to the class or collection role name) specifies the name of the second level cache region
  • 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  
Other wise we can specify the cache details to hibernate as <class-cache> and <collection-cache> elements in hibernate.cfg.xml.


The usage attribute specifies a cache concurrency strategy.The following are the summary of the four types of strategies.
1) Read Only: if your 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

2) 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

--
Sidd
http://javaexp.blogspot.com/

Comments

  1. AnonymousNovember 26, 2011 at 12:39 AM

    If you copy from Hibernate documentation , at least copy all the information.

    ReplyDelete
  2. AnonymousJuly 23, 2012 at 12:51 AM

    Hi, I have created a post [here](http://anirbanchowdhury.wordpress.com/2012/07/23/hibernate-second-level-cache-ehcache/)
    explaining the differences. Please have a look and feel free to comment.

    ReplyDelete

Post a Comment

Popular posts from this blog

Difference between volatile and synchronized

By -
volatile is a field modifier, while synchronized modifies code blocks and methods. So we can specify three variations of a simple accessor using those two keywords: int i1; int geti1() {return i1;} volatile int i2; int geti2() {return i2;} int i3; synchronized int geti3() {return i3;} geti1() accesses the value currently stored in i1 in the current thread . Threads can have local copies of variables, and the data does not have to be the same as the data held in other threads. In particular, another thread may have updated i1 in it's thread, but the value in the current thread could be different from that updated value. In fact Java has the idea of a "main" memory, and this is the memory that holds the current "correct" value for variables. Threads can have their own copy of data for variables, and the thread copy can be different from the "main" memory. So in fact, it is possible for the "main"
Read more

Converting Java Map to String

By -
Java Collections framework, String manipulation etc is something that we often encounter in Development process. For processing collections (like checking null/empty, Intersection, Disjunction) We do have some of the very use full libraries. Some of the Collection related libraries are Apche Commons Collections and Google  Collections(Guava). Problem Use Case This article explains how to convert a Java Map to String(and vice versa) using different libraries and technique. One way is to use StringBuilder(Or String) and loop though the Map and build the String by applying some sort of separator ( for key:value and entry). Here we have to take care of the null value etc. Without Any Library If we want to convert the map to a String with key value separator and also individual entry seperator in the resulting String, we have to write code for that. For a simple Map, we have to iterate though the map, take care of the null values etc. Following is a sample to get String built
Read more

Masking Credit Card number in Java

By -
Sometimes we need to mask crucial information like Credit Card Numbers, CVV numbers etc before storing  or logging the information. This example mask Credit Card Number (Except last 4 Digit) from a Text which contains information along with Credit Card Number. The following example demonstrates how we can easily mask the credit card with Matcher and Pattern Classes. This Sample Code uses Matcher and Pattern. Pattern Used in this sample is not optimized for Credit Card Numbers, this pattern will get any numerical numbers in the String Content.  Based on the Credit Card Type a more efficient and Strict RegEx can be used to mask the Credit Card. /**Mask the Credit card number but last four digit value **/   Pattern PATTERN = Pattern.compile( "[0-9]+" ); String message = content; Matcher matcher = PATTERN.matcher(message); String maskingChar = "*"; StringBuilder finalMask = new StringBuilder(maskingChar);
Read more