Introduction to Cache Loaders and Writers

Note: Ehcache clustering is not yet compatible with cache-through.

This section documents the specifics behind the cache-through implementation in Ehcache. Refer to the section Cache Usage Patterns if you are not familiar with terms like cache-through, read-through, write-through or system of record.

Ehcache merges the concepts of read-through and write-through behind a single interface, the CacheLoaderWriter.

As indicated by its API, this interface provides methods with logical grouping:

The load(K) and loadAll(Iterable<? super K>) methods cover the read-through part of cache-through.

The write(K, V), writeAll(Iterable<? extends Map.Entry<? extends K, ? extends V>>), delete(K) and deleteAll(Iterable<? super K>) methods cover the write-through part of cache-through.

The reasoning behind having a unified interface is that if you want a read-through only cache, you need to decide what to do about mutative method calls. What happens if someone calls put(K, V) on the cache? This risks making it inconsistent with the underlying system of record.

In this context, the unified interface forces you to make a choice: either no-op write* / delete* methods or throwing when mutation happens.

For a write-through only cache, it remains possible by simply having no-op load* methods.

An additional feature provided by Ehcache is write-behind, where writes are made asynchronously to the backing system of record. The way this works in Ehcache is by simply telling the system to register a wrapper around your provided CacheLoaderWriter implementation.

From there, you will have extra configuration options around batching and coalescing of writes.

Ehcache does not support retry of failed writes at the write-behind wrapper level. You, as the application developer and system of record owner, know better when a retry should happen and how. So if you need that functionality, make it part of your CacheLoaderWriter implementation.

Indicates how many pending write operations there can be before applying back pressure on cache operations.

Indicates how many parallel processing threads and queues there will be for write behind. Effectively the maximum number of in-flight writes is "concurrency level * queue size".

Mutative operations will be grouped in batch size sets before reaching the CacheLoaderWriter. When batching, the queue size is effectively the number of pending batches there can be. This means that the maximum number of in-flight writes becomes "concurrency level * queue size * batch size".

When batching, coalescing means that you only send the latest mutation on a per key basis to the CacheLoaderWriter.

When batching, you can indicate the maximum write delay for an incomplete batch. After this time has elapsed, the batch is processed even if incomplete.