An answer from November 2011 by Darin Dimitrov, a high-reputation member of Stack Overflow, claims that, emphasis mine:
HttpRuntime.Cache is much more than a simple dictionary. It offers thread-safety and cache expiration policies. It provides possibilities of using custom implementation and benefit from distributed caching which is helpful in web farms.
On the other hand, a few other questions more specific about distributed caching indicate that HttpRuntime.Cache is not the right choice:
Is it possible to share HttpRuntime.Cache between multiple web servers?
No, you can't share the built-in ASP.NET cache [...]
Suggestions for simple .NET distributed caching solution
Question:
Our site is written in ASP.NET 4.0 [...] using the standard
HttpRuntime.Cacheobject [...]Answer from December 2011 by Darin Dimitrov:
memcached along with an ASP.NET provider is a popular choice. Bear in mind though that in .NET 4.0 the recommended way to do caching is to use the new
ObjectCacheinstead ofHttpRuntime.Cache.Do HttpRuntime.Cache support for network load balancing?
No, Cache is per application (or app pool probably - I'd have to check that).
As I understand it from what I recall about .NET caching when using it a few years ago, HttpRuntime.Cache can be coupled with different implementations of actual caching: in-memory caching, but also any custom provider, such as a one for Redis. This is probably done at configuration level so that the actual code which uses HttpRuntime.Cache wouldn't bother about the location where cached data is stored and the way it is stored (and one could switch from provider to another without modifying the source code).
If this is true, I imagine that this pushed Darin Dimitrov in his original answer to suggest HttpRuntime.Cache as a solution for distributed caching. Since then, no actual implementations of distributed caching providers were made by Microsoft or third-parties, so HttpRuntime.Cache appeared less and less interesting.
Is my understanding correct?
