title: Changing the TTL of individual entries in EHCache 3
body: <p>In EHCache 2.x, it was possible to set a time to live on an individual entry in a cache, for example:</p>
  
  <pre><code>Element dependentElement = cache.get(key);
  long lastAccessTime = dependentElement.getLastAccessTime();
  long creationTime = dependentElement.getCreationTime();
  int timeToLive = lastAccessTime == 0 ? 300 : (int)
    (lastAccessTime - creationTime) / 1000 + 300;
  timeToLive += 2;
  dependentElement.setTimeToLive(timeToLive);
  </code></pre>
  
  <p>This would update the TTL of the individual item, thus keeping it in cache longer.</p>
  
  <p>In EHCache 3.x this seems no longer possible to do on an individual cache entry basis. After reading the <a href="http://www.ehcache.org/documentation/3.1/migration-guide.html#per-mapping-expiry" rel="nofollow noreferrer" title="Migration Guide">Migration Guide</a> and <a href="https://stackoverflow.com/questions/37697751/how-to-change-a-ehcache-members-expiry-time-programmatically">this question</a>, it seems to me this functionality is not directly migratable.</p>
  
  <p>The guide tells us that in order to modify the TTL, an interface has to be implemented:</p>
  
  <pre><code>CacheConfigurationBuilder.newCacheConfigurationBuilder(Long.class, 
      String.class, ResourcePoolsBuilder
      .withExpiry(new Expiry&lt;Long, String&gt;() {    
        @Override
        public Duration getExpiryForCreation(Long key, String value) {
          return getTimeToLiveDuration(key, value);   
        }
  
        @Override
        public Duration getExpiryForAccess(Long key, ValueSupplier&lt;? extends String&gt; value) {
          return null;  // Keeping the existing expiry
        }
  
        @Override
        public Duration getExpiryForUpdate(Long key, ValueSupplier&lt;? extends String&gt; oldValue, String newValue) {
          return null;  // Keeping the existing expiry
        }
      });
  </code></pre>
  
  <p>This configuration is then added to a cache to be initialized. However, it does appear that, since it's a cache-level extension point, you can never guarantee that the methods are triggered for the actual entry you want to change?</p>
  
  <p>Looking at the internals of EHCache 3, it seems that the good old <em>net.sf.ehcache.Element</em> is abstracted away and changed into a <em>ValueHolder&lt;V&gt;</em> and that it is no longer possible to access this.</p>
  
  <p>So, the question is: how can we implement the same behaviour in EHCache 3.x?</p>