Option to renew memory cache upon receiving BackplaneMessageAction.EntrySet

[angularsen]

From docs it seems memory cache for node 2 and 3 is evicted when node 1 updates the distributed cache with GetOrSet().

Proposal:

• Add option to choose between eviction and renewal of memory cache when receiving BackplaneMessageAction.EntrySet, defaulting to eviction for backwards compatibility.
• Configure globally or per cache entry

Pros:

• Minor response time improvement on nodes 2 and 3 on their first request after the value is changed
• Improved resilience on nodes 2 and 3, in case distributed cache is temporarily unavailable

Cons:

• If the value is rarely accessed or load-balancer only routes traffic to some nodes, then
  • Memory cache may store redundant data
  • Redis may be hit by redundant traffic

[jodydonetti]

Hi @angularsen , I can confirm that your understanding is correct: cache entries will be evicted on nodes 2 and 3 when there's an update on node 1.

A couple of notes behind these design decisions:

• the data is not sent directly with the notification because that would consume an enormous amount of bandwidth and, more importantly, it may not be needed since not every node may need the cache entry being updated
• for the same reasons the data is not immediately refreshed on each nodes, since that would cause a higher number of requests (one per cache entry, per each node) and again, not all nodes may need it

One additional note, which I think is very important: the cache entries are NOT completely removed from each nodes' memory cache when notified of a change, but only evicted in a "special way", meaning that they are basically marked as expired but are still there to be used as a fallback in case of problems/timeouts.
By simply using fail-safe and soft timeouts, you can guarantee fast response times even on the other nodes, even after their local copy has been evicted by a remote update on another node.

Maybe I should augment the backplane docs to better clarify this, will do asap.

Anyway, having specified all of this, I'm wondering if you still think it would be a good idea to automatically refresh cache entries after a change: what do you think?

While waiting for your opinion I'll comment on your other points:

Proposal:
Add option to choose between eviction and renewal of memory cache when receiving BackplaneMessageAction.EntrySet, defaulting to eviction for backwards compatibility.

If adding this, it would have to be added on the FusionCacheEntryOptions so to be able to have a fine-grained control over that. Also, the cache entry refresh should probably do SOME of the normal related things (eg: events) but NOT all of them (eg: notifications, to avoid a cascade effect).

Configure globally or per cache entry

This is automatically the way in FusionCache, thanks to the use of the forementioned FusionCacheEntryOptions in combination with the global DefaultEntryOptions, which serve as a default to start with: setting an hypothetical AutoRemoteRefresh (or something) prop to true there would serve as a default, and it would then be possible to change that per-call, all for free.

Pros:
Minor response time improvement on nodes 2 and 3 on their first request after the value is changed

This is already there thanks to fail-safe + soft timeout

Improved resilience on nodes 2 and 3, in case distributed cache is temporarily unavailable

This is already there thanks to fail-safe

Cons:
If the value is rarely accessed or load-balancer only routes traffic to some nodes, then
Memory cache may store redundant data

Exactly

Redis may be hit by redundant traffic

Yep

Let me know if you still think this feature would be necessary.

Thanks!

[jodydonetti]

Hi @angularsen , I just updated the backplane docs to better clarify how the notifications behave.

Hope this helps.