jodydonetti
commented
3 years ago Hi @sanllanta , thanks for using FusionCache!
Design-wise in FusionCache there's a difference between the primary (memory) and secondary (distributed) layers, and they are not treated in the same way (more on this here, just at the beginning).
Why?
This is because writes to the secondary layer should not interfere with the normal application flow, at least by default: applications consuming the cache should "think locally", knowing that the data will be propagated (if a distributed cache has been properly configured) in a kind of "best effort" way.
You can even enable background processing of these operations on the distributed cache, by setting FusionCacheEntryOptions.AllowBackgroundDistributedCacheOperations to true, to have an even better performance.
Now, regarding your observation about RunAsyncActionAdvancedAsync: you are in fact correct, and that is the case because of the reasoning I described above.
Example
In a typical scenario you get some data from a database and save it in in the cache to avoid executing a query every single time: if one write does not go well, we will simply try again the next time, no big deal.
This is just to give you an idea of how I designed it, I hope I've been able to explain my thought process.
Can you instead give me an example of why, in your use case, it can be problematic to just wait the next round to update the distributed cache? I'm curious to understand more.
But (because there's always a but 😄)
I have to say that the use case you described may make sense, even if I think that normally it is more common to use the distributed cache with a "best effort" approach, since it's secondary.
I have to think about it a little bit more, but here are 2 possible directions.
Idea 1
As mentioned, there's already the FusionCacheEntryOptions.AllowBackgroundDistributedCacheOperations option: what I may add is another option, something like FusionCacheEntryOptions.ReThrowDistributedCacheExceptions that, if set to true, would do what you are asking (and basically drive that bool reThrow param you mentioned).
Of course I should think (and document) about how it should behave with the other existing options.
An example is what if you allow background distributed cache operations? Then it would not make sense to rethrow, since the code has already moved on, right?
Another one is distributed cache timeouts (both soft and hard): if you set one of those, should I rethrow the timeout exception or, in that specific case, ignore it? Or should the timeouts and/or the background execution be automatically disabled if the new flag is set to true?
Another important point to consider is this:
- you call a
Setmethod - it saves the data in the memory cache
- it tries to save the data in the distributed cache
- but it's not able to do it, because the distributed cache throws an exception
- now what about the data saved in the memory cache? The data is there, and the next
Getthat will be executed would find it "normally", but your code (that called theSetmethod) receives an exception, and it may seem counter intuitive to have the data saved in the memory cache
I mean it seems kinda easy at first, but we should think about side effects + edge cases.
Idea 2
The code that works with the distributed cache already has an integrated small circuit breaker, that deals with transient errors.
An idea may be to also add a little retry logic, with some configurable options like int MaxRetries and TimeSpan RetryDelay.
But I was hesitant about adding too much about that, and in fact I mentioned in the docs that you can use something more specific, like Polly (which is already used by some official .NET libs).
Why am I hesitant about that? Because what may seem "easy" like "retry a couple of times" can in fact hide a lot, like the concept of "exponential backoff" and other things like that.
Let me know
Anyway I'm open to some idea, so let me know what you think about my observations and we can work something out!
sanllanta
jasenf
I'm using the library to store values in Redis. When saving data with the
SetAsyncmethod I've found that it doesn't fail the task when an exception occurs when saving the data. I would like to be able to recover from this scenario as I need to ensure that the data was saved successfully. Whats the best way of handling this scenario?, digging into the code I see that theRunAsyncActionAdvancedAsyncinFusionCacheExecutionUtilshas areThrowattribute that would solve the issue, but it is always being passed as false with no way to override it. I believe I could simply fetch the value afterwards withTryGetbut think it would be easier if there was a way to know if the Set method failed.Thanks for your help. I'm really liking the library so far.