Hibernate Community • View topic - Second Level Cache

View unanswered posts | View active topics

Board index » Hibernate & Java Persistence » Hibernate Users

All times are UTC - 5 hours [ DST ]

Second Level Cache - Preventing data conflict

Page 1 of 1

[ 4 posts ]

Previous topic | Next topic

Author

Message

bluesky2

Post subject: Second Level Cache - Preventing data conflict

Posted: Fri Feb 08, 2013 7:30 am

Newbie

Joined: Fri Feb 08, 2013 7:15 am
Posts: 2

Hi All,

My application is running on two servers with two JBoss AS 5 instance. Application architecture depends on Spring and Hibernate.

I try to enable Hibernate Second Level Cache via a cluster covering two nodes. Transactions are managed by Spring App Context(with org.springframework.orm.hibernate3.HibernateTransactionManager). I use RO, NSRW and RW cache conccurency strategies.

I have two questions as the following :

1) Both Hibernate and Cache(H2LC) operations should be in the same transaction in order to prevent data conflict between cache and database. I could not find any detailed documentation. How can it be implemented? or Does Hibernate already manage?

2) There is a description in Hibernate Documentation(http://docs.jboss.org/hibernate/orm/3.6/reference/en-US/html/performance.html#performance-cache) as "If the cache is used in a JTA environment, you must specify the property hibernate.transaction.manager_lookup_class and naming a strategy for obtaining the JTA TransactionManager." For my situation, i think it is not required. Do you have any comment?

Installation :

Hibernate 3.6.4
Spring 3.0.5
JBOSS AS 5

Thanks...

Top

pb00067

Post subject: Re: Second Level Cache - Preventing data conflict

Posted: Tue Feb 12, 2013 4:07 am

Expert

Joined: Tue Jun 16, 2009 3:36 am
Posts: 990

Quote:

1) Both Hibernate and Cache(H2LC) operations should be in the same transaction in order to prevent data conflict between cache and database.

Sorry, but the Hibernate Second Level Cache aka shared cache is per definition a cache which stays behind transactions.
Therefore the first part of your sentence makes no sense.

To prevent data conflict between shared cache and database you must synchronize the shared caches of your 2 nodes.
There exist several ways to reach this.

Quote:

2) ... For my situation, i think it is not required. Do you have any comment?

Well, it does in first line depend on the 2ndLevel cache implementation you choose.
If you for example decided to take Infinispan as 2ndLevel cache implementation,
then you are forced to use the JTA approach, since Infinispan is a pure transactional 2ndLevel cache implementation.
transactional 2ndLevel cache implementation means that the 2ndLevel cache get involved in current transaction,
in such way that changed cache entries get not shared to others until regarding transaction isn't yet committed.
If you choose indeed a implementation like EHCache which works as well as a transactional and as well as a non-transactional 2ndLevel cache, then you are free to take JTA approach or not.

Top

bluesky2

Post subject: Re: Second Level Cache - Preventing data conflict

Posted: Tue Feb 12, 2013 12:01 pm

Newbie

Joined: Fri Feb 08, 2013 7:15 am
Posts: 2

Firstly thanks for your response.

Quote:

the Hibernate Second Level Cache aka shared cache is per definition a cache which stays behind transactions.

Could you please explain more detailed?

Quote:

To prevent data conflict between shared cache and database you must synchronize the shared caches of your 2 nodes.
There exist several ways to reach this.

How?

Top

pb00067

Post subject: Re: Second Level Cache - Preventing data conflict

Posted: Wed Feb 13, 2013 3:41 am

Expert

Joined: Tue Jun 16, 2009 3:36 am
Posts: 990

First level cache and second Level cache, explanation:
The first level cache is the persistent context itself and is a transactional cache.

The second level cache is optional and also called shared cache.
Shared because its purpose is to share data to all sessions.
Such data must be consolidated, that means it must be commited data, not any uncommitted dirty data, ok?
In other words: the shared cache principal purpose, is to cache data which is not in transaction.

Quote:

How?

This depends on the concrete second Level cache implementation you are using.
If you are for example using EHCache you can synchronize the two 2L-caches using RMI, or JGroups or JMI.
http://ehcache.org/documentation/replication
If you use Infinispan, there are other mechanisms to sychnronize the 2L-caches in a cluster.
Both cache implementors are well documented, so you will find enough informations and examples in internet.

Here an example how I configured the replication overRMI with EHCache:

Code:

<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../config/ehcache.xsd" updateCheck="false">
       <cacheManagerPeerProviderFactory
              class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
              properties="peerDiscovery=automatic, multicastGroupAddress=224.0.0.1,
                                  multicastGroupPort=4446, timeToLive=32"/>

  <cacheManagerPeerListenerFactory class="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory" 
          properties="socketTimeoutMillis=120000"/>
  <!--  cacheManagerPeerListenerFactory
            port=40001 don't set this if you deploy a unique ehcache.xml: let it be dynamic, each virtual machine must get a different port 
            properties="hostName=localhost, socketTimeoutMillis=..." this produces a warning, if you explicitly set a hostName then it should not be 'localhost'
            
         cacheEventListenerFactory  
                  replicatePuts=          true | false - whether new elements placed in a cache are replicated to others. Defaults to true.
                  replicateUpdates=       true | false - whether new elements which override an element already existing with the same key are replicated. Defaults to true.
                  replicateRemovals=      true | false - whether element removals are replicated. Defaults to true.
                  replicateAsynchronously=true | false - whether replications are asynchronous (true) or synchronous (false). Defaults to true.
                  replicateUpdatesViaCopy=true | false - whether the new elements are copied to other caches (true), or whether a remove message is sent. Defaults to true.
    -->
           
  
    <!--
    Mandatory Default Cache configuration. These settings will be applied to caches
    created programmatically using CacheManager.add(String cacheName)
    -->
    <defaultCache
            maxElementsInMemory="10000"
            eternal="false"
            timeToIdleSeconds="120"
            overflowToDisk="false"
            memoryStoreEvictionPolicy="LRU">
    </defaultCache>
            
    
    <cache  name="Eternal" 
            maxElementsInMemory="40000"
            eternal="true"
            overflowToDisk="false"
            memoryStoreEvictionPolicy="LRU">
            <cacheEventListenerFactory class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"
                           properties="replicateAsynchronously=true, replicatePuts=true, replicateUpdates=true, replicateUpdatesViaCopy=true, replicateRemovals=true "/>
    </cache>
            
</ehcache>

Top

Page 1 of 1

[ 4 posts ]

Board index » Hibernate & Java Persistence » Hibernate Users

All times are UTC - 5 hours [ DST ]

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum