In our series on software caches in Java application servers,
we evaluated Ehcache, Hazelcast,
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
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
- 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
Infinispan. In client-server
set-ups, they are supported by Hazelcast,
Terracotta, which is Ehcache’s
- 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
- 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.