How to Configure .NET 4.0 Cache to use a Distributed Cache?

In-memory distributed cache today has become really popular for applications running in a multi-server environment because it helps improve application scalability and performance. Until .NET Framework 3.5 there was ASP.NET Cache object available only for web application under System.Web.Caching namespace. But, in .NET Framework 4.0, .NET 4.0 Cache is added under System.Runtime.Caching namespace for all types of .NET applications. .NET 4.0 Cache has functionality similar to ASP.NET Cache. But, unlike ASP.NET Cache, it has an abstract class ObjectCache that can be implemented in a customized way as needed. So, in essence .NET 4.0 Cache can be extended which ASP.NET Cache cannot be. And, MemoryCache is the default in-memory cache implementation of .NET 4.0 Cache. Here is an example:

Key Takeaways

Architectural Shift: .NET 4.0 introduced System.Runtime.Caching, replacing the web-limited System.Web.Caching with a universal, extensible framework for all .NET application types.
The ObjectCache Advantage: Unlike the sealed ASP.NET Cache, the .NET 4.0 ObjectCache is an abstract class, allowing third-party providers like NCache to plug in and extend caching capabilities.
Solving the “In-Process” Limitation: The default MemoryCache is a stand-alone, in-process solution. NCache transforms this into a distributed cache, providing consistent data synchronization across multi-server web farms and clusters.
Direct Integration: Developers can transition to a distributed environment with minimal code changes by initializing the NCache.ObjectCacheProvider while maintaining standard .NET 4.0 features like ChangeMonitors and CacheItemPolicies.
Enterprise Features: NCache’s implementation includes specialized monitors (NCacheSqlChangeMonitor, NCacheFileChangeMonitor) to invalidate cache entries based on external database or file system changes.

One limitation of .NET 4.0 Cache’s default implementation MemoryCache is that it is a stand-alone in-process cache, which lacks the data synchronization required for multi-server web farms. If your .NET application runs on a multi-server environment, then you cannot use this because you need a distributed cache that can synchronize the cache across multiple servers. But fortunately, .NET 4.0 Cache architecture allows us to plug in a third party distributed cache solution and extend it.

Feature	ASP.NET Cache	.NET 4.0 Cache (ObjectCache)	NCache Distributed Provider
Namespace	System.Web.Caching	System.Runtime.Caching	Alachisoft.NCache.ObjectCacheProvider
Primary Implementation	Cache Object	MemoryCache (Default)	CacheProvider
Extensibility	Sealed: Cannot be customized or extended.	Abstract: Uses ObjectCache base for custom providers.	Extended: Plugs NCache into the .NET 4.0 framework.
Application Scope	Web Applications only.	All .NET Apps (Console, WinForms, Web).	Enterprise-Scale (Multi-server clusters).
Storage Architecture	In-Process (Local RAM).	In-Process (Local RAM).	Out-of-Process (Distributed).
Multi-Server Sync	No: Each server has a different data silo.	No: Stand-alone in-process implementation.	Yes: Real-time synchronization across web farms.
Change Monitoring	Limited to Files/Keys.	HostFileChangeMonitor	NCacheSql/Oracle/File Change Monitors.
Scalability	Vertical (Single Server).	Vertical (Single Server).	Horizontal (Add nodes to the cluster).

• NCache Details
• Download NCache
• Edition Comparison

To address this need, Alachisoft has implemented an easy to use .NET 4.0 Cache Provider that can solve data synchronization, distribution and scalability issues especially in case of web farm/garden. This provider basically integrates NCache with .NET 4.0 Cache. NCache is a very popular enterprise level distributed cache for .NET. Through NCache’s .NET 4.0 Cache Provider you can plug in NCache with your application to achieve the benefits of a distributed cache. Let me show you how easily it can be done with NCache by a few steps.

1. Create a Clustered (distributed) cache through GUI based NCache Manager. I created a clustered cache named as “MyClusterCache”.
2. Start the cache to make it ready to use.
3. Add references of  Alachisoft.NCache.ObjectCacheProvider library to your application from “NCacheInstallDir/NCache/integration/DotNet4.0 Cache Provider“
4. Include the following namespace in your project.
   
   1	using Alachisoft.NCache.ObjectCacheProvider;

5. Initialize your CacheProvider (inherited from ObjectCache) and pass your cache name to the provider as shown below.
   
   1 2 3 4

   ObjectCache _cache; string _cacheId = "MyClusterCache" ; _cache = new CacheProvider(_cacheId);

6. Now you can perform all cache related operations on your cache using CacheProvider commands.

Here is full example of .NET 4.0 extended for NCache:

NCache implementation of .NET 4.0 Cache also includes custom implementation of ChangeMonitor as NCacheEntryChangeMonitor, NCacheFileChangeMonitor, NCacheSqlChangeMonitor and NCacheOracleChangeMonitor for entry, file, SQL and Oracle based changes respectively. Through NCache’s implementation of .NET 4.0 Cache interface, you can now adopt .NET 4.0 Cache as your standard and at the same time benefit from an enterprise level distributed cache for your .NET applications running in a multi-server environment.

• NCache Details
• Download NCache
• Edition Comparison

Frequently Asked Questions (FAQ)

Q: Can I use the same CacheItemPolicy with NCache that I used with MemoryCache?
A: Yes. Because NCache implements the standard .NET 4.0 ObjectCache interface, your existing CacheItemPolicy objects (including priorities and expiration settings) are fully compatible. NCache interprets these policies and applies them across the distributed cluster.

Q: How does the NCache Provider handle file-based dependencies in a web farm?
A: Standard .NET HostFileChangeMonitor only works for files on the local server. NCache provides the NCacheFileChangeMonitor, which allows the cache to react to file changes across multiple nodes, ensuring that if a configuration file is updated on one server, the cache is invalidated globally.

Q: Does switching to the NCache CacheProvider require changing my existing CRUD logic?
A: No. Since CacheProvider inherits from ObjectCache, you continue to use standard methods like cache.Add(), cache.Set(), and cache.Get(). The only change required is the initialization of the _cache object to point to your NCache clustered ID instead of MemoryCache.Default.

Q: What happens if the connection to the clustered cache is lost?
A: NCache is designed for high availability. Unlike the default MemoryCache, which resides in the application’s memory space, NCache runs as a separate service. If one node in the cluster fails, the data remains available on other nodes, preventing a complete cache flush.

Q: Are SQL and Oracle dependencies supported in this extended .NET 4.0 implementation?
A: Yes. NCache provides custom implementations such as NCacheSqlChangeMonitor and NCacheOracleChangeMonitor. These allow you to synchronize your cache with database changes, a feature that is not natively available in the standard .NET 4.0 MemoryCache.