Feature request: unconditional expiration of entries based on absolute age (time since load)

[oakad]

Presently, the cache supports "TTL after access" and "TTL after write" expiration policies. In some cases, however, it is handy to expire objects based on their absolute age - essentially "TTL after load" (one usage example of this policy are authenticated network sessions which must expire unconditionally even if client keeps sending data). Considering that this policy is probably easier to implement that the 2 already existing expiration policies, may the Caffeine benefit by providing it as well?

[ben-manes]

I'd prefer to leave this to a pending feature, variable expiration. That is more complicated to do correctly, but carries a much higher power-to-weight ratio. Otherwise we'd be stuck trying to provide one-off solutions for the easy problems, which adds usage and implementation complexity, with little overall gain.

I have a general idea for how to implement variable expiration in O(1) time by using a timer wheel variant. That's nicer than the common solutions of requiring either a O(lg n) priority queue or relying on a maximum size to discard dead entries. But I haven't prototyped it, so unfortunately its on the backlog at the moment.

[oakad]

Suddenly I realized than issue #70 talks about the same thing, so sorry for double posting.

Could you kindly point me to the description of "variable expiration" feature (if it exists in some written form, that is)? I have looked around but could not quite establish what exactly you mean by that.

[ben-manes]

In memcached it might be set(key, value, duration, TimeUnit), where key1 and key2 can have expire at different intervals. That makes sense for a shared cluster, e.g. a session token has a 1 hour expiration that's being refreshed constantly, whereas a password reset token might be 48 hours.

Memcached does the above by setting an expiration timestamp. When an entry expires it fakes a miss and the entry eventually gets removed due to a LRU eviction. The alternative is an O(lg n) priority queue, but that's expensive to maintain. The timer wheel approach is an alternative used by kernels that I'd like to explore.

[ben-manes]

See these slides for a talk I'll be giving soon. There is a section showing a hierarchical timer wheel.

[oakad]

Thank you, most interesting.

[ben-manes]

This feature is implemented, but additional tests are needed before release. You would be able to perform this expiration by using,

Caffeine.newBuilder().expiry(new Expiry<K, V> {
  public long expireAfterCreate(K key, V value, long currentTime) {
    // return expiration duration, e.g. 5 minutes
  }
  public long expireAfterUpdate(K key, V value, long currentTime, long currentDuration) {
    return currentDuration
  }
  public long expireAfterRead(K key, V value, long currentTime, long currentDuration) {
    return currentDuration;
  }
}).build()

[oakad]

This is most impressive (TimerWheel in particular).
Thank you for your effort.

[ben-manes]

Released 2.5.0