-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Comments
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 |
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() |
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
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
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
Thanks, that is great. |
Released 2.5.0 |
Maybe it is supported out of the box, but I haven´t discovered this option.
Background:
Is this possible? Any chance to get this into the library?
Thanks,
Jens
The text was updated successfully, but these errors were encountered: