Standalone/Replicated Ehcache for cluster

Question

In our project, we decided to use Ehcache in our application as a second level cache for Hibernate and query caching. It seems to be working well.

Then suddenly we realized that our production environment is clustered. Looking at the ehcache documentation, I see that the best thing would be to go for distributed caching but then that involves Terracotta Server, something the client won't be prepared to pay for at this stage.

According to the documentation, for the Standalone topology:

If standalone caching is being used where there are multiple application nodes running the same application, then there is Weak Consistency between them.

My two questions are:

1. Using ehcache in a "Read-only" mode and continuing to use it standalone in a clustered environment, what is the hit that we would be taking? Because if it only that say, for the cases it would hit the other nodes, it would fetch the data off the DB as cache won't be replicated/configured there, I guess we'll take it. Only thing is, it should not result in an anomaly. I would want to know the consequences of using standalone topology for my scenario.

2. Can we look at the third topology, Replicated Caching, as a solution?

I am new to ehcache and hence these basic questions. Replies much appreciated!

thanks!

Answer 1

If your application is clustered and you need to cache data which may change, you will need to use a caching solution which supports this. As you say, if you wish to use EhCache in a cluster you will need to use Terracotta.

The Hibernate documentation lists supported cache providers here.

I have implemented this successfully using Infinispan (the open source JBoss solution to distributed caching). There is a comprehensive guide here which will give you everything you need to get up and running.

Infinispan supports multiple modes of operation, including invalidation, replictaed and distributed. The default for the 2LC is synchronous invalidation. In this mode when an entity is updated on a node in the cluster it will invalidate the cache region and all other nodes will be informed and will do the same.