Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support of expiring entries based on the initial write of the entry #70

Closed
jgoldhammer opened this issue Apr 24, 2016 · 4 comments
Closed

Comments

@jgoldhammer
Copy link

Maybe it is supported out of the box, but I haven´t discovered this option.

Background:

  • I want to expire an entry in the cache after a certain time amount the entry was created initially in the cache. I don´t think that the other options expireAfterAccess and expireAfterWrite do not work here (https://github.com/ben-manes/caffeine/wiki/Eviction#time-based).
  • the entry will be updated during this timeframe a lot, so expiringAfterWrite does not work for me...

Is this possible? Any chance to get this into the library?

Thanks,
Jens

@ben-manes
Copy link
Owner

ben-manes commented Apr 24, 2016

Perhaps this is better handled in your code? There is a complexity budget and, when its only a little painful for a special case, I think the trade-off favors not adding.

You could avoid a write into the cache for an update by using a holder value. For example,

Holder<V> holder = cache.asMap().putIfAbsent(key, new Holder<>(newValue));
if (holder != null) {
  holder.setValue(newValue);
}

This type of usage would make expireAfterWrite behave the way you want. There may be a few small quirks depending on the enabled features.

@ben-manes
Copy link
Owner

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()

ben-manes added a commit that referenced this issue May 1, 2017
The expiration time can now be customized on a per entry basis to allow
them to expire at different rates. This is acheived in O(1) time using
a timer wheel and evaluating using the new Expiry interface. This
setting can be combined with refreshAfterWrite, but is incompatible
with the fixed expiration types (expireAfterAccess, expireAfterWrite).

While the test suite was updated to incorporate this new configuration
option, there is still remaining work before this should be released.
 - New tests specific to this feature (such as exceptional conditions)
   have not yet been written
 - Incorporate a data integrity check for the timer wheel into the
   validation listener
 - Inspection through cache.policy()
 - JCache integration
 - Documentation
ben-manes added a commit that referenced this issue May 1, 2017
The expiration time can now be customized on a per entry basis to allow
them to expire at different rates. This is acheived in O(1) time using
a timer wheel and evaluating using the new Expiry interface. This
setting can be combined with refreshAfterWrite, but is incompatible
with the fixed expiration types (expireAfterAccess, expireAfterWrite).

While the test suite was updated to incorporate this new configuration
option, there is still remaining work before this should be released.
 - New tests specific to this feature (such as exceptional conditions)
   have not yet been written
 - Incorporate a data integrity check for the timer wheel into the
   validation listener
 - Inspection through cache.policy()
 - JCache integration
 - Documentation
ben-manes added a commit that referenced this issue May 1, 2017
The expiration time can now be customized on a per entry basis to allow
them to expire at different rates. This is acheived in O(1) time using
a timer wheel and evaluating using the new Expiry interface. This
setting can be combined with refreshAfterWrite, but is incompatible
with the fixed expiration types (expireAfterAccess, expireAfterWrite).

While the test suite was updated to incorporate this new configuration
option, there is still remaining work before this should be released.
 - New tests specific to this feature (such as exceptional conditions)
   have not yet been written
 - Incorporate a data integrity check for the timer wheel into the
   validation listener
 - Inspection through cache.policy()
 - JCache integration
 - Documentation
@jgoldhammer
Copy link
Author

Thanks, that is great.

@ben-manes
Copy link
Owner

Released 2.5.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants