-
Notifications
You must be signed in to change notification settings - Fork 38
Cache invalidation #38
Comments
endpoints that mutate state should invalidate the previous cached item by default as you mention. It would also be beneficial to have the ability to inject a service that allows invalidating cached items on demand. For example an event received over a bus may mutate the objects state which would require invalidation. This may however be out of scope and better handled by abstracting the cache to a different layer? |
@glennc If we want to do this in the future, we should get together and agree on a design. |
Any update on this? Cache invalidation would be a killer feature both for REST API interactions, but also SignalR or other types of event buffers/message queues that cause the underlying data to mutate. |
This issue was moved to dotnet/aspnetcore#2622 |
Currently we only set the absolute timeouts for cache entries. There is no mechanism to explicitly invalidate a cache entry before expiry. Also, how would applications/users interact with this feature?
Note that invalidation is required by the RFC for unsafe methods, e.g. a successful PUT should invalidate any previous cached resources at the same URI.
The text was updated successfully, but these errors were encountered: