|
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 be 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.
1.
Install NCache
on each server where your
application is running
2.
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.
3. 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;
4. 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.
|