Scale Up Enterprise Library Caching Block
NCache provides extremely fast and highly scalable distributed cache for Caching Application Block that is part of patterns & practices Enterprise Library from Microsoft. NCache is a distributed in-memory object cache for .NET and lets you greatly scale up Caching Application Block.
Distributed In-Memory Object Cache for EntLib
Distributed cache, the core engine of NCache, is extremely fast and scalable. Cache both static and transactional application data and reduce expensive database trips. NCache synchronizes cache updates across multiple servers.
- 100% cache uptime thru replication and dynamic cache clustering
- Scale up with Mirrored, Replicated, Partitioned, and Client Cache topologies
- Software appliance for Caching Application Block (no code change required)
Drawbacks of Regular CAB
Microsoft CAB is an in-process cache for stand-alone .NET application. Following are some of its drawbacks:
- ASP.NET worker process recycling problem: Worker process recycling destroys the entire cache which has a negative performance impact on your app.
- ASP.NET web gardens problem: ASP.NET app runs in multiple worker processes in a web garden configuration. This creates multiple in-process copies of the cache that are not synchronized with each other and lead to data integrity errors.
- ASP.NET web farms problem: ASP.NET apps frequently run in web farms for scalability reasons. A stand-alone cache is unaware of multiple servers and cache instances and is not synchronized. This leads to data integrity problems.
- Application scalability problem: If your .NET application needs to scale up and run on multiple servers, your cache must be distributed. Otherwise, it would cause data integrity problems.
- Large cache size problem: In-process cache means it cannot grow more than what your app process can handle. A distributed cache on the other hand can grow in size through distribution.
Benefits of NCache as Distributed Cache for CAB
NCache is a distributed cache that lets you improve your application performance and also scales up very nicely when your application needs to scale up. Below are some of the benefits of using clustered sessions:
- Handles ASP.NET worker processes well: NCache can be used out-of-process. This means multiple ASP.NET worker processes can share a common out-of-process cache. This also addresses worker process recycling problem because the cache is not affected by it.
- Handles ASP.NET web farms: NCache creates a clustered cache that can live on multiple servers. This allows your ASP.NET apps and .NET web services to run in web farm configuration without worrying about cache synchronization issues.
- Highly scalable: You have a rich set of clustering topologies (replicated, partitioned, and client nodes) that allow you to scale up to 100’s of web servers in your farm without compromising on performance.
- No single point of failure (high availability): Clustering the cache allows you to eliminate all single points of failures from your environment. This makes your application highly available.
- 100% Native .NET: NCache is a 100% native .NET product. This means that you can expect us to stay on top of all additions and changes to .NET as compared to a non-.NET solution.
How Does It Work?
Using NCache as a distributed cache for CAB is very simple. It requires only namespace change in your application. NCache implements the same public interface as CAB but has a different namespace. You only change the namespace from regular CAB to NCache-CAB and everything starts working seamlessly.

Incorporating NCache into your .NET application using CAB is a simple three-step process as described below.
- Install NCache on each server where your application is running
- Define a clustered cache: Use NCache Manager (a graphical tool) to define a clustered cache that is appropriate for you. You should select replicated cache, partitioned cache, or partition-replica cache. And, you can also specify whether the cache should reside on the same server as your application or whether you should have a separate caching tier (again a cluster of multiple cache servers) where all the cache is kept. For larger configurations, a separate caching tier is more appropriate.
- Modify namespace from CAB to NCache to start using Distributed CAB module provided by NCache. You can download this module from the download page. Here is the namespace you need to specify for NCache Distributed CAB module. Please note that instead of "
Microsoft.Practices" as the prefix to namespaces, you'll be using "Alachisoft.NCache" as the prefix:
using Alachisoft.NCache.EnterpriseLibrary.Caching;
using Alachisoft.NCache.EnterpriseLibrary.Caching.Expirations;
using Alachisoft.NCache.EnterpriseLibrary.Caching.Configuration;
- Modify your app.config or web.config to specify that you want to use NCache Distributed CAB instead of your regular CAB. Here is what you need to specify in app.config:
<configuration>
<configSections>
<section name="cachingConfiguration"
type="Alachisoft.NCache.EnterpriseLibrary.
Caching.Configuration.CacheManagerSettings,
Alachisoft.NCache.EnterpriseLibrary.Caching,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=null"/>
</configSections>
<cachingConfiguration defaultCacheManager="myReplicatedCache">
<cacheManagers>
<add name="myReplicatedCache" mode="OutProc" exceptions="true"/>
<add name="myCache" mode="InProc" exceptions="false"/>
</cacheManagers>
</cachingConfiguration>
Once you do this, you’re .NET application is ready to start using a distributed cache. Please make sure that Version matches the exact version of Distributed CAB you're using. The above example of app.config or web.config contains the following options for you to configure. Each of them is explained below as well.
- cacheManager name: This option lets you specify a cache name that you have created through NCache Manager tool. CAB then connects to this particular cache.
- cacheManager mode: This option lets you specify whether you want to access the cache InProc or OutProc. We recommend that you use OutProc for distributed cache and either InProc or OutProc for a local cache.
- exceptions: This option lets you specify whether you want Distributed CAB to throw excptions if there are any or supress and ignore them.