Cluster-Aware EhCache using JMS in webMethods

Did you know? You can create fully cluster-aware EhCache applications using JMS without having terracotta setup at all.

I have seen many organizations investing in terracotta just to make their cache cluster aware. But fact is, messaging systems are a very mature piece of infrastructure used in many enterprise level organizations. So, they can leverage their messaging system investment for caching too.

Before going into details on how to achieve this, I want you all to understand that messaging systems are NOT replacement for Terracotta in whole. Terracotta is a very powerful product in the world of data handling. It has got robust implementation in dealing with BigMemory, Quartz Schedulers, Web Sessions etc.. whose details are out of the scope of this article.

So, this article benefits you if you are just looking for a way to make your ehcache cluster aware without having terracotta. Having said this, lets see how to achieve the same.

How it looks now with Terracotta:


How will it look with JMS:


Ehcache replicates using JMS as follows:

  • Each cache node subscribes to a predefined topic, configured as the <topicBindingName> in ehcache.xml.
  • Each replicated cache publishes cache elements to that topic. Replication is configured per cache.


EhCache comes with an out of box module called JMS Replication module. But the same does not come along with EhCache that is part of webMethods product suite. So, the first thing to do is,  download the supported version of ehcache-jmsreplication.jar from


Well, it is quite simple as all the core logic sits inside the replication module that you just downloaded.


Place the ehcache-jmsreplication.jar file you downloaded under <SoftwareAG Installation Directory>/Integration Server/lib/jars and restart the Integration Server. Check if this jar module is loaded into server JVM by looking in About page on IS Admin console.


We need to have a fixed JMS Topic for replication. Set up a JMS Topic on Universal Messaging (UM) or Broker using Naming directories (JNDI)


Last but not least, configuration inside CacheManager.xml file.

There are two things to configure:

  • The JMSCacheManagerPeerProviderFactory which is done once per CacheManager and therefore once per ehcache.xml file.
  • The JMSCacheReplicatorFactory which is added to each cache’s configuration if you want that cache replicated.
  1. Go to IS Admin page -> Settings -> Caching, Shutdown the cache manager on which you want to configure the JMS replication.
  2. Locate the cache manager XML file under “<SoftwareAG Installation Directory>/IntegrationServer/config/Caching” folder
  3. Make changes to the XML as shown in sample below.
  4. Go back to IS Admin page -> Settings -> Caching, Start the cache manager

Below is a sample ehcache.xml file content with JMS replication configured. I have used Universal Messaging (UM) in this sample, but the same can be configured using Broker too:

<ehcache name=”TestRep” updateCheck=”false”>
<diskStore path=”./cacheStore/TestRep”/>
propertySeparator=”,” />

Voila!! That’s it!! You are done.

Now you can go to your Software AG Designer and start writing the code using caching API’s from WmPublic/pub/cache namespace like you always did. No special flags… No special or extra code to make it cluster aware. All the Integration servers or Java clients having the same ehcache xml configuration on their side will be automatically synchronized when any changes happen on this cache by any one of them.

That’s cool right?? You can now say Bye.. Bye.. to Terracotta if you are using it to just do the same job till now 🙂


3 thoughts on “Cluster-Aware EhCache using JMS in webMethods

    1. Yes Farid. If you want to have cluster aware locking then you have to set the property “replicateAsynchronously” to “false” in the “cacheEventListenerFactory” section under CacheManager xml file. This will make the replication synchronous and any atomic locks (read/write) will block all other processes access to the cache until it successfully replicates the data change to all other processes that use the cache.


  1. The ehcache team hasn’t maintained/supported/promoted the jms replication module in years now. It has known problems with ordering of events and therefore data consistency issues. This cannot be resolved as it it built upon the Ehcache 2.x event listeners, which have the same underlying problem.

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s