Tuesday, October 6, 2009

JBoss caching is a very powerful caching mechanism developed and as far as i know this is the only Tree Cache implementation currently available. If i give a briefing on what caching is all about, caching allows you to minmize the time you go to the database to fetch data. We all know how costly database access is, and caching allows us to minmize those calls by caching the results fetched from the database. Ofcourse a general rule of thumb in caching is that you should always consider caching data that rarely change but frequently access.

There are many caching implementations out there, some being OSCache, EHCache, Teracotta (if im not mistaken this does allow caching as well) and many more are out there. I havent used these, but was involved in integrating OSCache at one point. OSCache is pretty much ok if your application is running on a single instance. When it comes to clustering, it becomes a bit complicated to configure OSCache. But still it is possible by the usage of Multicast addresses to publish cached data to multiple clusters but it is awfully complicated. And OSCache does not get involved in Transactions as far as i can remember. This is where JBoss caching comes in.

JBoss caching seamlessly integrated into a clustered environment with only a few configurations and most importantly it gets involved in Transactions and hence it only caches the data if the transaction successfully committs. And if your entities are updated within a transaction, so will the data in the cache be updated and works the same if rows are deleted from the database. Following I will show you how to integrate JBoss caching to your JBoss AS. I wanted to publish this article because although there was alot of documentation availabel on caching(JBoss does have comprehensive documentation) the information was dispersed so my intention of this article is to provide step by step operations to integrate JBoss caching. Following shows how to use JBoss caching with Hibernate.

Before i start explaining how to integrate JBoss caching there are some details you need to be aware of.

JBossCache versions prior to 1.2.2 are not recommended for use with Hibernate, due to deadlock issues that may arise.

Hibernate versions prior to 3.0.2 are not recommended for use with JBossCache, for the same deadlock issues mentioned above.

Hibernate >= 3.2 is required if you plan to use Optimistic Locking. JBoss Cache >= 3.0.0 and Hibernate >= 3.3.0 is your optimal configuration, using MVCC as a locking scheme on JBoss Cache.

Im using Jboss cache 1.4.1 with Hibernate 3.2 so that i can use the Optimistic Locking feature provided.

The above list was taken from the Jboss wiki. Please have a look at the configuration table provided in that too to find the optimal configuration suited for you.

First of all you need to get the jboss caching distribution. Extract the jboss-cache.jar and jgroups.jar from that distribution as thats all you need. Im currently using jboss caching 1.4.1 with JBoss AS 4.2.2 GA. Place these two jars withing your deployment lib folder. For example /yourjbosslocation/server/default/lib. If you are using the "all" distribution the jgroups.jar will already be available to you. But in production you will almost always have your won deployment configuration.

Afterwards you need to define your caching implentation to be loaded as a service as MBeans. The following is the xml file ejb3-entity-cache-service.xml which you can find in your "all" configuration. The following file is edited a bit to include optimistic features.

<!-- Must be true if any entity deployment uses a scoped classloader --> <attribute name="UseRegionBasedMarshalling">true</attribute> <!-- Must match the value of "useRegionBasedMarshalling" --> <attribute name="InactiveOnStartup">true</attribute>

<!-- The max amount of time (in milliseconds) we wait until the initial state (ie. the contents of the cache) are retrieved from existing members. --> <attribute name="InitialStateRetrievalTimeout">17500</attribute>

<!-- Number of milliseconds to wait until all responses for a synchronous call have been received. --> <attribute name="SyncReplTimeout">17500</attribute>

<!-- Max number of milliseconds to wait for a lock acquisition --> <attribute name="LockAcquisitionTimeout">15000</attribute>

<!-- Name of the eviction policy class. --> <attribute name="EvictionPolicyClass">org.jboss.cache.eviction.LRUPolicy</attribute>

The above file needs to be put in your "deploy" folder so that the caching service can find the configuration. In the above you can see I have used the "NodeLockingScheme" attribute and set it to "OPTIMISTIC". This is what allows for OptimisticLocking to take palce. Note that this will only work if you are using Hibernate 3.2. Else you should use the "IsolationLevel" attribute. In this same file i have defined that attribute as well but as i have used the "NodeLockingScehem" attribute, which overrides the "IsolationLevel" attribute. And if you look at the "CacheMode" attribute i have set it to "REPL_SYNC". If you look at the JBoss wiki link i have given above it states the following;

If you are only using a query cache or collection cache, use REPL_ASYNC.

If you are only caching entities, use INVALIDATION_SYNC

If you are using a combination of query caching and entity caching, use REPL_SYNC.

Hence my use case is that i will be using query and collection cache as well as entity cache and hence REPL_SYNC is the ideal configuration.

Afterwards i want to move your focus to the region tags specified within the xml configuration above. If you only keep the default region then what happens is all the caching will be stored in one specifc region. If its entity caching then it will be stored in the default region with the fully qualified class name. Hence it is always best to separate your caching regions on entity basis or whatever basis you deem appropriate. One thing to keep in mind is to provide a meaningul eviction time as you do not want to keep your data forever in the cache. I have defined one caching region in the above configuration. I will next show you how to map this region name in your entity class. Below i give you the entity bean class which shows how to enable caching at the entity level.

Here i have done a collection caching. You need to defined the usage and the region. If you do not specify the region it will be stored in the default region as i mentioned before. You may have noted that i have only said the region name to be "Seating" but in the configuration file which was shown before it said "/mycache/Seating". If you are caching a collection of objects please note that you should define that specifc entity as cacheable too. This brings us to the next topic which defines an entity to be cacheable.

One thing to note here is that if you are using the "JOIN FETCH" statement in your queries do not cache those as the caching wont work for those kind of queries.

Lastly there is one last step to compelte the integration. You need to tell hibernate that you want to enable 2nd level caching and that you are going to be using the JBoss caching implementation. Provide the following parameters in your persistence.xml file or .hbm file.

Now i come back to the part of why we only defined the region name in the previous entity as only "Seating". Its because we have given the "hibernate.cache.region_prefix" property the value "mycache" and hence the region will always be relative to "/mycache". And of course you need to tell hibernate to enable second level and query caching which is stated above. And the other properties are self explaining as far as i can see.

Well folks, thats about it on how to integrate JBoss caching to your Jboss AS. If you come acorss any difficulties please do contact me as i would very much like to help you.