Set up both TTL and TTI in Ehcache 3 XML configuration

Question

What I am trying to accomplish is to set up both TTL (time to live) and TTI (time to idle) for a cache, so that the key either expires after TTL time or it can be expired earlier in case in hasn't been accessed for TTI period.

In Ehcache 2 it was possible with the following configuration:

<cache name="my.custom.Cache"
       timeToIdleSeconds="10"
       timeToLiveSeconds="120">
</cache>

In Ehcache 3 the analogous configuration block looks like the following:

<cache alias="my.custom.Cache">
    <expiry>
        <tti unit="seconds">10</tti>
        <ttl unit="minutes">2</ttl>
    </expiry>
</cache>

The problem is that such configuration is considered invalid since ehcache.xsd states that there should only be one option under expiry tag (either tti or ttl, but not both).

Answer 1

As mentioned by Louis Jacomet on the mailing list:

In order to achieve what you want, you need to create a custom Expiry, which you can do with the Expirations.builder() that was introduced in 3.3.1, or with a custom implementation of the Expiry interface.

Note however that your explanation of what the expiration did in Ehcache 2 is slightly incorrect. When you combine TTL and TTI, the element remains valid for the whole TTL whether it is accessed or not. However, if it is accessed close to the end of the TTL period, the last access time + TTI can make it stay for longer in the cache. And if it is access again during that period, the last access time is updated again thus extending the life of the mapping.

The way Expiry works in Ehcache 3 is slightly different, as effectively we compute an expiration time each time the mapping is created, accessed or updated. This is done to reduce overhead in stored mappings.

So if you configure your Expiry with getExpiryForCreation returning 120 seconds but getExpiryForAccess returning 10 seconds, a created but never access element will be considered expired after 120 seconds. While a created but accessed element will be considered expired 10 seconds after the last access, even if that time is still within the 120 seconds. TTI is really a weird concept when you think about it, that we kept for JCache compatibility, but which is effectively closer to eviction than expiration. Because what does it mean for the freshness of a value that it is being read? While it indeed means this is a useful value in the cache that should not be evicted.

And in XML, you cannot use the tti and ttl shortcut in combination. But you can configure an expiry by fully qualified class name. We should consider extending the XML system so that you can do some equivalent of the added builder in code.