5 ms·

so.... if I initially got the key "foo" at time T=00:00:00, this library would re-query the backing system until time T=00:00:60? even if I requery it at T=:01?

so.... if I initially got the key "foo" at time T=00:00:00, this library would re-query the backing system until time T=00:00:60? even if I requery it at T=:01? vs... being a write-through cache? I guess you're expecting other entries in the DB to go around the cache and update behind your back. if you are on that threshold window, why not a period where the stale period is okay? T0-60 seconds, use the first query (don't retrigger a query) T60-120 seconds, use the first query but trigger a single DB query and use the new result. repeat until the key is stale for 600 seconds. that is, a minimum of 2 queries (the first preemptive one at 60 seconds, (in the cache for 10 minutes total) and a maximum of 11 queries (over 10 minutes) (the initial one that entered the key, and if people ask for it once a minute, a preemptive one at the end of those minutes, for 20 minutes total in the cache).

zimpenfish 2y ago
> if I initially got the key "foo" at time T=00:00:00, this library would re-query the backing system until time T=00:00:60? even if I requery it at T=:01? From what I understood of the README (10 minute expiry, 1 minute window) only cache requests between 09:00 to 09:59 will trigger a pre-emptive backing fetch. ie. T0-539 seconds uses the first query (no re-fetch), T540-599 does a pre-emptive re-fetch (as long as no-one else is currently doing that), T600- would do a fetch and start the whole timer again.
- bnkamalesh 2y ago
  @zimpenfish yes you are right. refetch is initiated on the first Get between 9-10mins, and the timer is reset as soon as the back fetch is successful
  - NovaX 2y ago
    One optimization for background refresh is coalescing the individual reloads into a batch operation based on a time/space window. Here is how we do it in the Java world. [1] [1] https://github.com/ben-manes/caffeine/tree/master/examples/coalescing-bulkloader-reactor#readme https://github.com/ben-manes/caffeine/tree/master/examples/c...
    - mh- 2y ago
      Thank you for your OSS work! I used Caffeine many years ago.
      - NovaX 2y ago
        Oh thank you, I’m glad it’s been helpful.
    - bnkamalesh 2y ago
      aha yes! It's in my todo list to introduce bulk updates. On the other hand, I'll be publishing a batcher package soon which does something very close to what you suggested here. Thank you

zimpenfish 2y ago

> if I initially got the key "foo" at time T=00:00:00, this library would re-query the backing system until time T=00:00:60? even if I requery it at T=:01? From what I understood of the README (10 minute expiry, 1 minute window) only cache requests between 09:00 to 09:59 will trigger a pre-emptive backing fetch. ie. T0-539 seconds uses the first query (no re-fetch), T540-599 does a pre-emptive re-fetch (as long as no-one else is currently doing that), T600- would do a fetch and start the whole timer again.

bnkamalesh 2y ago
@zimpenfish yes you are right. refetch is initiated on the first Get between 9-10mins, and the timer is reset as soon as the back fetch is successful
- NovaX 2y ago
  One optimization for background refresh is coalescing the individual reloads into a batch operation based on a time/space window. Here is how we do it in the Java world. [1] [1] https://github.com/ben-manes/caffeine/tree/master/examples/coalescing-bulkloader-reactor#readme https://github.com/ben-manes/caffeine/tree/master/examples/c...
  - mh- 2y ago
    Thank you for your OSS work! I used Caffeine many years ago.
    - NovaX 2y ago
      Oh thank you, I’m glad it’s been helpful.
  - bnkamalesh 2y ago
    aha yes! It's in my todo list to introduce bulk updates. On the other hand, I'll be publishing a batcher package soon which does something very close to what you suggested here. Thank you