multi_caching causes invalid TTL entries about cache-manager

[BryanDonovan]

Hmm. I see the benefits of your proposed solution, but I'm not seeing an easy solution that fits all scenarios.

The original intent of the multi-cache, if used with a memory cache, is to have a very short TTL for the memory cache compared to the lower cache. E.g, you would perhaps only want to cache data in memory with a TTL of 5 minutes with a redis backend that has a TTL of 24 hours.

I don't think most people would have the higher level cache have a similar TTL as the lower level cache, and therefore wouldn't want the higher cache to receive the remaining TTL from the lower cache.

Providing options that allow this to be configurable seems like it would be pretty confusing. I'm open to ideas though.

[vmattila]

I am bumbing up this issue/question as struggling also with some inconsistency in multi_caching policies.

In my opinion, TTL values should always be considered as maximum time an entry is kept in cache. Store implementations can always purge the cache entry before TTL but "never" after. Thus, higher level caches should always have lower TTL than lower level level caches. For me, it makes no sense to have TTL of 10 sec in memory but 5 sec in redis.

TTLs per item are indeed tricky. Again, in my personal opinion, if default TTL for a store is lower than item TTL, the store TTL should be used. For example, if I have cache layers memory (10 sec TTL) and redis (60 sec TTL), and then set item with TTL 30 sec; memory layer should have it for 10 sec and redis for 30 sec.

I did also notice that https://github.com/theogravity/node-cache-manager-memory-store does not implement TTL at all, so all cache items would be kept in cache forever, won't they? This might be worth another issue & PR though. ;)

[BryanDonovan]

Thanks @dcolens. Do you want to try implementing this? Otherwise I can try when I have time, but it might be a week or so.

[astanciu]

Any updates on this? Seems like a pretty big problem for multi-caching...

[BryanDonovan]

Sorry, I didn't hear back from you.. I was wondering if you wanted to try implementing the solution. I'm pretty busy these days but will get to it eventually.

[dcolens]

I don't have time right now for implementing, I found the issue while experimenting with multi-caching, I like the concept a lot!

[BryanDonovan]

I'm not sure how feasible this is. The problem I see is that you don't necessarily know the TTL of the entry from the lower cache, so you can't be sure to pass it up to the higher cache.

I might be missing something, but it seems like the worst case scenario is a rare cache miss.. correct me if I'm wrong though.

[dcolens]

In the scenario where multiple servers are used for load balancing it will cause cache inconsistency. For example: serverA caches entryA, serverB gets a query for entryA it finds it in the lower level cache and caches it in the mem cache, now entryA will still be present in serverB while it already expired in serverA.

In my use case, this made the functionality unusable. So yes, in my opinion the lower level caches should return the remaining TTL when queried in a multi-cache scenario.

[websocket98765]

I did also notice that https://github.com/theogravity/node-cache-manager-memory-store does not implement TTL at all, so all cache items would be kept in cache forever, won't they? This might be worth another issue & PR though. ;)

I haven't looked into the implementation, but wanted to note I tested the built-in memory store tonight using a TTL set on the memory store, and it worked successfully--it returned cached items within the TTL timeframe and returned undefined after the expected TTL elapsed. (Edit: I didn't test the OP's issue. Just confirming that memory cache doesn't cache forever.)

[zzau13]

Fixes by #203