Although caching allows to to have higher performance and scalability, there is no free lunch. Applications that use extensive caching run the risk of showing the user stale data. ASP.NET allows you to evict items from the cache based on several parameters including time, memory usage, and priority. There are also dependency objects that allow you to evict items from the cache when the underlying database changes.
AppDomains and Caching boundaries
In ASP.NET the AppDomain is your application boundary. This is a security perimeter, but also a housekeeping one. For our discussion, each AppDomain has its own cache object. What does this mean for us?
- If you have a main website, and four subsites that are ASP.NET applications, then you will have 5 Cache objects that are not guaranteed to be synchronized.
- If you have one ASP.NET application and web gardens set up with 2 worker processes, then you will have two Cache objects that are not guaranteed to be synchronized
- If you have a web farm with three servers, then you will have 3 cache objects that are not guaranteed to be synchronized.
Third Party Caching Solutions
If we combine the two issues above, the situation only gets worse. You can run into a situation where you have multiple caches with different data. An application may update data that invalidates its cache, but has to notify the other caches to evict this item as well. As you can see from the examples above, you may need a distributed caching solution even if you only have one web server. I’ve investigated three products that can provide a distributed cache across AppDomains, processes and servers.