ehcache3 | Ehcache 3x line | Wiki library

Ehcache 3 strictly enforces the XSD, so the elements inside a cache or cache-template must be in the following order:

1. key-type
2. value-type
3. expiry
4. eviction-advisor
5. loader-writer
6. listeners
7. resources OR heap
8. more ...

with all elements being optional aside from the sizing (place 7) which is optional in a cache-template though.

It's not possible. By design.

We do not calculate size when the limit is entries. For performance reason. Keeping track of the size is quite costly.

However, I think in your case, I would do a sizeof. If you don't need it that often, just do a sizeof of the cache and it will give you the current cache size nicely.

Your question contains the answer, you need either to use the null object pattern or a related solution to wrap / hide your nulls.

There is no, and there will not be, support for null key or values in Ehcache 3.

This is currently not possible as-is because there is an XSD validation on that field, which prevents the value from starting with such characters.

However, you can trick that XSD validation by doing the following:

As you can see in sources of org.springframework.cache.jcache.JCacheCacheManager Spring doesn't understand that it should use method getCache(String, Class, Class) instead of simple getCache(String). More precisely this class doesn't know anything about getCache(String, Class, Class).

So you have three ways:

1. Do nothing as during get and put operations cache uses equals() and may be hashCode() methods from real class of your key. Only discomfort is in explicit type casting if you use direct access to cache instead of declarative access via annotations.

2. Extends this class and study it to understand these cache config features.

3. Look at another CacheManager that might know these settings.

The default is NO_ADVICE

From the javadoc :

Returns an {@link EvictionAdvisor} where no mappings are advised against eviction.

There is no such thing in Ehcache 3 at the moment. JCache does not have that option either.

You cannot size a resource to 0 so that's not an option either.

From here, two options:

• add a layer in your application doing the indirection and add the disabled support to that.
• Make a feature request on the Ehcache users mailing list to get it considered for addition.

I will post here the same answer as on the ehcache mailing list.

An Expiry implementation can be very dynamic and select the expiry time using a given cached key and value.

If you know that you did something like Expirations.timeToLiveExpiration(Duration.of(20, TimeUnit.SECONDS)) to create it, then, it won't be dynamic. So you can do cache.getRuntimeConfiguration().getExpiry().getExpiryForCreation(null, null) to get the duration of a cache entry after creation.

If you then want to dynamically change the TTL, it is possible but you will need to provided your own Expiry implementation (not really hard to do). With a setter for the TTL.

However, the new value will only apply to new added entries. Existing entries won't see their TTLs changed. This is because we calculate the expiration timestamp when the entry is added. Instead of reapplying the duration all the time. For performance reasons.

Accepting 4 entries onheap means that there can be 4 entries. Whatever the size. So if your heap is small and your objects large, you can indeed get and OOME.

Your solution is to give your heap store a maximum memory size (256) instead of a number of entries.

That way, entries will be evicted when needed and before getting an OOME (assuming the maximum memory size is lower than what's left on your heap).