«Top»

In our series on software caches in Java application servers,
we evaluated Ehcache, Hazelcast,
and Infinispan.

Starting with a simple example application,
we deployed each of these cache implementations in local,
peer-to-peer, and client-server
mode.

This page summarizes some of the results.

• The API of all three caches is very similar, as each of them provides
  a ConcurrentMap-like
  interface. It is easy to switch from one implementation to
  another as long as no proprietary extra API is used.
• The underlying networking architectures are very different. It is impossible
  to give a generic advice as to which cache is better. The performance heavily depends
  on the use case scenario.
• For WORM applications (write-once-read-many, i.e. data is stored in the cache
  once and rarely updated),
  fully replicated peer-to-peer architectures
  are a good choice, as they serve data locally without network interaction.
  These are provided by Ehcache
  and Infinispan.
• For applications updating data frequently or for applications requiring
  transactions, distributed hash tables are a good
  choice. In peer-to-peer set-ups, distributed hash tables are provided by
  Hazelcast and
  Infinispan. In client-server
  set-ups, they are supported by Hazelcast,
  Infinispan, and
  Terracotta, which is Ehcache’s
  server side.
• If an application does not have any consistency requirements, or if an
  application can guarantee that each key is only updated by one specific
  cluster node, performance can be significantly improved by choosing
  asynchronous configuration.
• When distributed consistency needs to be supported, the application should
  be thoroughly tested. The API must be used in a way that
  implements thread-safety without using synchronized blocks,
  and misconfiguration may result in inconsistent distributed caches even if
  the code relies on methods that are locally thread-safe.