Reply from November 2011 Darin Dimitrov, a senior member of Stack Overflow, claims my hit:
HttpRuntime.Cache is much more than a simple dictionary. It offers a thread restriction policy and a cache expiration policy. It provides custom implementation capabilities and the benefits of distributed caching, which is useful in web farms.
On the other hand, a few other questions, more specifically regarding distributed caching, show that HttpRuntime.Cache not the right choice:
Can I share HttpRuntime.Cache between multiple web servers?
No, you cannot use the ASP.NET built-in cache [...]
Suggestions for simple distributed .NET caching.
Question:
Our site is written in ASP.NET 4.0 [...] using the standard HttpRuntime.Cache object [...]
From December 2011 Darin Dimitrov:
memcached along with the ASP.NET provider is a popular choice. Keep in mind that in .NET 4.0, the recommended caching method is to use the new ObjectCache instead of HttpRuntime.Cache .
Does support HttpRuntime.Cache support for balancing network load?
No, the cache for the application (or probably the application pool - I have to check this).
As I understand it, from what I remember about .NET caching when using it several years ago, HttpRuntime.Cache can be combined with various implementations of actual caching: in-memory caching, as well as any custom provider, such as one for Radish. This is probably done at the configuration level, so the actual code that HttpRuntime.Cache uses will not worry about the location where the cached data is stored and how it is stored (and you could switch from provider to another without changing the source code).
If this is true, I believe that this prompted Darin Dimitrov to his initial answer, suggesting HttpRuntime.Cache as a solution for distributed caching. Since then, no actual implementations of the distributed caching providers have been made by Microsoft or third parties, which is why HttpRuntime.Cache turned out to be less interesting.
Do I understand correctly?
Arseni mourzenko
source share