Differences in Default Behavior between Ehcache and Ehcache through JCache

Ehcache used natively and Ehcache used through JCache do not always agree on default behavior. While native Ehcache can behave the way JCache specifies, depending on the used configuration mechanism, you may see differences in defaults.

Ehcache and Ehcache through JCache disagree on the default mode for heap-only caching.

Ehcache configuration with JCache MutableConfiguration

Unless you invoke MutableConfiguration.setStoreByValue(boolean), the default value is "true". This means that you will be limited to Serializable keys and values when using Ehcache.

Under the cover, this will trigger the use of serializing copiers and pick the appropriate serializer from the default ones. See the section Serializers and Copiers for related information.

Ehcache configuration with native XML or code

Heap only: When using heap only caches, the default is by-reference unless you configure a Copier.

Other tiering configuration: When using any other tiers, since serialization comes into play the default is "by-value".

See the sections Copiers and Serializers for related information.

Ehcache and Ehcache through JCache disagree on the role of the cache loader for compare-and-swap operations.

Ehcache through JCache behaviour

When using compare-and-swap operations, such as putIfAbsent(K, V), the cache loader will not be used if the cache has no mapping present. If the putIfAbsent(K, V) succeeds then the cache writer will be used to propagate the update to the system of record. This could result in the cache behaving like INSERT but effectively causing a blind update on the underlying system of record.

Native Ehcache behaviour

The CacheLoaderWriter will always be used to load missing mappings with and to write updates. This enables the putIfAbsent(K, V) in cache-through to behave as an INSERT on the system of record.

If you need Ehcache through JCache behaviour, the following shows the relevant XML configuration: