-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] Invalidation in future? #290
Comments
Hi @gercobrandwijk , sorry but I don't understand the issue here. The factory is involved/specified with cache.GetOrSet<Product>(
"my-cache-key",
_ => LoadValueFromDb(), // THIS IS THE FACTORY
TimeSpan.FromMinutes(5) // THIS IS THE DURATION
); By doing this, you are guaranteed that only after If you are currently invalidating the cache entry via But if you want to avoid that and want the expiration to occur only once every But maybe I'm missing something here, can you tell me more? |
I was in a hurry a bit, so I will try to make it a bit more clear... Setting the duration to 5 minutes is not want we want, because that means in our scenario that the factory will run every 5 minutes, which is inefficient as well when looking at the whole picture. Let me explain our scenario a bit more:
This means:
When that burst of requests is coming in (we do not know how many will come and what the latest request will be), I basically want to say 'invalidate this cache key over 10 min'. After that time period the burst of requests will be over, so than the factory will be called once (after it has been invalidated). Of course that means in that time period where the burst of requests comes in, the cached item has outdated information, but that's not a problem in our case. |
Ok now I understand, but just to be clear: we are talking about the very same cache key being invalidated repeatedly, right? Or different cache keys in sequence? Anyway this seems like a very specific scenario, one for which I'm not sure a specific FusionCache feture would be the best way to go, since there are different considerations and edge cases to consider. Because of your particular scenario, wouldn't it be enugh to start a timer in your own code that will expire the cache key after 10 min? Let me know what you think. |
Hi, also joining the conversation here! In my opinion it is indeed about the same key. Maybe we can also view this from the perspective that this would re-set the expiration to e.g. "10 min" if the expiration is longer then "10 min". Setting a timer in other code is possible, but also not really easy in distributed scenario's, although that's not the most important argument. |
Very same cache key indeed.
It has to invalidate directly which means that the 'invalidate over 10 min' is superseeded by the 'now-invalidation', so that invalidation can be cancelled / will not be executed anymore. |
@jodydonetti Little bump.. What is your opinion/insight on this? What would be your advice to implement this in a reliable way which takes the concurrency/timing problems into account? |
Hi @gercobrandwijk , sorry for the delay but I just came back from my (very late) summer vacations 😅
I don't feel like this is a candidate for an official feature for FusionCache, at least not right now, since the very specific edge case and potential consequences that have yet to be explored in full. Thanks! |
Looking forward to your POC :) |
I tried to use the FusionCacheEntryOptions overload of the ExpireAsync, to let it expire in 15 seconds:
But this seems not to be working; the factory is called directly after the Expire, instead of after 15 seconds. Maybe this can be an addition to FusionCache (which will also help in my scenario)? Thanks for all your efforts; love to hear for you! :) |
Problem
When having a lot of situations that can invalidate the same cache entry, this means that a lot of factory executions are needed, which can cause a huge load on the database.
Solution
I would like to be able to invalidate the cache 'in the future'. For example you want to invalidate the cache in 5 minutes. In this 5 minutes window, when other requests/services are invalidating the same key, it will already be scheduled for over 5 minutes. This means that at max every 5 minutes the factory will be called onces.
Is this an already existing feature which I overlooked?
Alternatives
Any workaround is also fine for me :)
The text was updated successfully, but these errors were encountered: