Jens Wilke

Its totally okay if you don't want to address this right now. But maybe its good to keep the issue open for somebody else to chime in.

The background refresh, as its implemented now, only stops after a single refresh if the data is not requested within the expiry period after the refresh. Can you explain your...

Here is an idea about a refresh policy: ```` class RefreshPolicy { /** * Called when the entry would expire and removed from the cached because * the previously refreshed...

Should be merged with https://github.com/cache2k/cache2k/issues/172. If we change to another mechanism to track the access, we could also recognize a second access after the initial load. This enables the possibility...

Another idea: class RefreshPolicy { int requiredAccessTimesUntilNextExpiry(CacheEntry, RefreshContext ctx); } class RefreshContext { boolean initialLoad(); long getExpiryTime(); long getModificationTime(); long getLastKnownAccessTime(); int getRefreshCountSinceLastAccess(); } The method is executed when a...

@denghongcai ping. Maybe you like to check and comment on the last idea.

@denghongcai thanks for sharing! In cache2k the expiry time is the time when an entry needs to be refreshed. Its identical. In old versions of cache2k I there was a...

@javalover123: The feature is still work in progress, I have still around 30 code sections I need to investigate, correct and test, so the that the policy is working correctly....

Also should have a `CacheLoader` with `CompletableFuture load(K key)`

Great to hear you are enjoying cache2k. Unfortunately, the annotation definitions need to be exported, since these are part of the API. I did a lot of experimentation. At the...