Configure cache expiry in @CacheResult annotation

[sbeigel]

I'm using Quarkus' app data caching to re-use an access token which expires after some time:

@CacheResult(cacheName = "foo-access-token")
String getAccessToken() {
	// retrieve access token from upstream service and re-use until it expires...
	return ...
}

I configured the expiry like this:

# config
quarkus.cache.caffeine."foo-access-token".expire-after-write=30M

I think it would be more consise and developer-friendly, if you could configure the expiry directly on the annotation like this:

@CacheResult(cacheName = "foo-access-token", expireAfterWrite="30M")
String getAccessToken() {
...

Or is there any reason you decided against this possibility?

[quarkus-bot[bot]]

/cc @gwenneg (cache)

[gwenneg]

Hi @sbeigel.

It looks like you're using Caffeine as the backend of quarkus-cache. As far as I know, the only way to configure an expiration policy with Caffeine is by doing so for an entire cache. Technically speaking, there's a way to implement an expiration policy on a per-entry basis, but it's a bit tricky as cached values need to be wrapped into an object that holds the expiration information.

@ben-manes Do you have a suggestion about the best approach to set an expiration delay on each cached value with Caffeine?

@CacheResult determines a caching behavior for a method. It cannot have any impact on the configuration of the cache it references because the same cache could be used in different @CacheResult annotations with different settings:

@CacheResult(cacheName = "foo-access-token", expireAfterWrite="30M")
String getAccessToken() { /* method body */ }

@CacheResult(cacheName = "foo-access-token", expireAfterWrite="5M")
String getAccessToken2() { /* method body */ }

This doesn't exclude the possibility to implement an expiration policy on a per-entry basis. Maybe the quarkus-cache API could include an interface that would need to be implemented to expire a cache entry:

public interface ExpirableCacheEntry {
    Duration expireAfterWrite();
    Duration expireAfterRead();
}

When the extension was created, Caffeine was the only backend available but today the extension also supports Redis as its backend. As a consequence, before modifying @CacheResult for Caffeine, the impact on Redis needs to be considered as well.

This is definitely an interesting topic so it's worth investigating further. Thanks for posting this question!

[ben-manes]

Caffeine supports per-entry expiration if configured to do so. It requires setting an Expiry to evaluate on unspecified cases like a cache load. There are some unreleased convenience functions, but the common usage would look like

LoadingCache<Geolocation, Address> cache = Caffeine.newBuilder()
    .expireAfter(Expiry.creating((Geolocation latLng, Address address) ->
        Duration.between(Instant.now(), address.resolvedOn().plusDays(30))))
    .build(key -> findAddress(key));
var address = cache.get(new Geolocation(latitude, longitude);

Where for example Google Maps allows one to cache address geocodings for 30 days, so one might persist them with a TTL and need the caches to also honor that limit. This means that the Expiry can evaluate the key-value to determine the lifetime after the entry is created, updated, or read.

That's the ideal usage, but reality is never so nice. Cache.policy() offers more feature specific methods, like put(key, value, duration), to support more ad hoc usage. This way one could set a default expiration time, e.g. eternal, and then override it explicitly for a given entry. This is snuck away to not pollute the ideal api and unblock users, so we'll keep adding as use-cases come up. For example for Oracle Coherence they needed compute(key, remappingFunction, duration) for their integration. If one needed that duration to be computed dynamically instead then we'd add it after some api sketching, as its hidden away so doesn't add conceptual weight for most users.

Cache<K, V> cache = Caffeine.newBuilder()
    .expireAfter(Expiry.creating((K key, V value) -> Duration.ofNanos(Long.MAX_VALUE))
    .build();
cache.policy().expireVariably().orElseThrows()
    .put(key, value, Duration.ofMinutes(10));

[sbeigel]

Hi,
thanks for your responses!

@CacheResult determines a caching behavior for a method. It cannot have any impact on the configuration of the cache it references because the same cache could be used in different @CacheResult annotations with different settings: [...]

@gwenneg: I understand your point, but if you configure expiry in you app.properties, it would affect both methods (in your example), so we could throw a warning of even an error during build time when there are multiple (conflicting) expiry-settings found on annotations.

Your suggestion of a new separate annotation to configure the expiry could be a last-resort solution if changing @CacheResult is not possible, still I think adding expiry to @CacheResult would be the most intuitive way from a developer's perspective.

My example was kind of the simplest case, of course the expiry should be on a per-entry basis -- and tbh, I though it was like this, if you think about:

@CacheResult(cacheName = "foo-access-token", expireAfterWrite="30M")
String getAccessTokenForUser(String username, String password) { /* method body */ }

Each user (username & pw) should have its own access token which should be re-used (aka cached) for 30 minutes, independent from other users' access tokens in the (same) cache, i.e. each entry has its own "lifetime". Is that not the case right now (unrelated to the config via annotations)?

Thanks,
Sebastian