GetAndSet?

[wileyveteran]

Is there a way to do a get and then use that value to modify only part of it and then set the updated value back into the cache as an atomic operation?

For some more background, we have a cache with both L1 & L2 but it is pre-filled from the db at startup. After that all updates are done via Set as messages come off our message bus. The message on the bus may only contain parts of the object stored in the cache e.g. 3 of 5 values hence why we would like to get from the cache first and apply updates to it. It is also important the cache has the most up to date information as soon as possible. These values do get written to the db but for preformance reasons we don't want to have to let them expire to then be retrieved from the db again as the general case. Is this possible?

Also messages for any given key tend to come in groups so we might get 5 messages for a given key almost simultaneously but then nothing for hours and items may stay in the cache for a couple of days with a fixed expiration time.

Maybe this is the wrong solution but the other features like cache stampede protection etc. make it appealing.

[jodydonetti]

Hi @wileyveteran

Is there a way to do a get and then use that value to modify only part of it and then set the updated value back into the cache as an atomic operation?

It's not possible, because the operations FusionCache can rely on are the ones available in the IMemoryCache and IDistributedCache interfaces. I can add stuff on top of them (like I did with fail-safe, tagging, etc) but in this case you are asking for an atomic operation, and that requires support from the underlying levels, which is not the case.

And here I'm not even talking about IMemoryCache or IDistributedCache, let's get deeper: in this case in particular where we talk about an atomic operation let's forget for a moment about FusionCache, let's forget about the IDistributedCache abstraction and let's even forget about StackExchange.Redis (the underlying .NET client library for Redis). For atomic operations like the one you mentioned to be possible, Redis (the server) itself must support it at a fundamental level: this means that even by working directly with Redis via a CLI or via the lowest possible driver available, the operation is not available inside of Redis itself (and FWIW it's not available even in others like Memcached, MongoDB, etc).

Also messages for any given key tend to come in groups so we might get 5 messages for a given key almost simultaneously but then nothing for hours and items may stay in the cache for a couple of days with a fixed expiration time.

I would need to know more details about the scenario, but one thing I can think about is that you may work with a lower Duration to reduce as much as possible a potential stale value, and do as much as possible active evictions on changes via backplane notifications.

Maybe this is the wrong solution but the other features like cache stampede protection etc. make it appealing.

Understandable, and on top of stampede protection the community keeps telling me that when they start using features fail-safe, eager refresh or soft timeouts (oh, and auto-recovery, that is really helpful when 💩 hit the fan) they become quite useful tools in their toolbelt which they rely on.

Let me know if Ican help you more.

[wileyveteran]

Thanks. I thought that may be the answer. I see that redis 8 has been released with support for partial updates of json documents so I may need to look at a pure redis solution for my use case.