Setting both expireAfterAccess and expireAfterWrite policies as they're no mutually exclusive

[kvajjala59]

What is the behavior when we set both eviction policies expireAfterAccess and expireAfterWrite? Which does take preference?

[ben-manes]

I don't recommend using both, as it is a quirk in Guava that we mirror for compatibility (and perhaps should not have). You can use expireAfter(expiry) instead.

The two timestamps are maintained independently, so it is whatever has the shortest duration. expireAfterAccess will update its timestamp on every read or write, so it depends on which fixed duration is smaller. If 30s access and 5 min write, then absent of writes the access policy will evict. If the access duration is equal or greater, then the write policy will be dominant if only reads occur. I don't think there is a use-case that benefits by having both enabled.

[kvajjala59]

Thanks :)

[WChrisGraham]

Not sure what qualifies this behavior as a "quirk"; it's just what I was hoping for -- I see it as useful.

Same case as @Blackbaud-JasonBodnar described, but minutes rather than days.
If no one's using the data in 5 minutes, let it drop.

Don't keep data more than 30 mins, regardless of popularity, as it would be too stale.
Don't keep data more than 5 mins, if it is unpopular.

Mind you, since the cache does its own expiry when full, we still have to prepare for the cache hitting full size and then having items turfed.
In which case, expireAfterAccess is always "just" a way to force a certain amount of LRU behavior, when the cache would otherwise be influenced by other considerations?

[ben-manes]

yep, you're correct. I am just unsure if that is wise compared to relying on size eviction to make decisions, since it handles both recency and frequency. If it was a pure LRU then the expireAfterAccess aging helps avoid pollution, e.g. one-hit wonders. Since size eviction uses an admission window that is dynamically sized based on the hit rate, it does a very good job in all of our workload traces. I'd rather that expireAfterWrite be combined with maximumSize than expireAfterAccess, if a user was only going to pick one of those schemes. There is no plan on removing this combination, but I probably wouldn't add it again if starting anew (e.g. porting to a new language).

[Blackbaud-JasonBodnar]

What about the case where you want to evict unused entries after 1 day and all entries 3 days after they were written regardless of when they were last accessed? IE, you want to make sure nothing cached is older than 3 days so it's not too stale.

[ben-manes]

At peak usage the cache is limited by its capacity bound, so evicting unused after 1 day for memory savings still requires planning for a worst case of everything kept to the 3 days threshold at peak usage. Instead expiration is for data freshness, with expireAfterAccess to bound to a known lifetime (e.g. session-scoped). In your example you might consider using a scheduled task to purge those entries since the time durations are so large. There is no plan on removing this combination, it is just rarely a helpful setting (and should be documented as to why if both are used).

[Blackbaud-JasonBodnar]

Makes sense! Thanks for the clarification.