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

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.