The Cache object is unique in its capability to automatically scavenge the memory and get rid of unused items. Cached items can be prioritized and associated with various types of dependencies, such as disk files, other cached items, and database tables. When any of these items change, the cached item is automatically invalidated and removed. Aside from that, the Cache object provides the same dictionary-based and familiar programming interface as Session. Unlike Session, however, the Cache object does not store data on a per-user basis. Furthermore, when the session state is managed in-process, all currently running sessions are stored as distinct items in the ASP.NET Cache.

Keep in mind that an instance of the Cache class is created on a per-AppDomain basis and remains valid as long as that AppDomain is up and running. If you’re looking for a global repository object that, like Session, works across a Web farm or Web garden architecture, the Cache object is not for you. You have to resort to AppFabric Caching services or to some commercial frameworks (for example, ScaleOut or NCache) or open-source frameworks (for example, Memcached or SharedCache).

The Cache class provides a few properties and public fields. Table 18-1 lists and describes them all.

The NoAbsoluteExpiration field is of the DateTime type and is set to the DateTime.MaxValue date—that is, the largest possible date defined in the Microsoft .NET Framework. The NoSlidingExpiration field is of the TimeSpan type and is set to TimeSpan.Zero, meaning that sliding expiration is disabled. I’ll say more about sliding expiration shortly.

The Item property is a read/write property that can also be used to add new items to the cache. If the key specified as the argument of the Item property does not exist, a new entry is created. Otherwise, the existing entry is overwritten.

Cache["MyItem"] = value;

The data stored in the cache is generically considered to be of type object, whereas the key must be a case-sensitive string. When you insert a new item in the cache using the Item property, a number of default attributes are assumed. In particular, the item is given no expiration policy, no remove callback, and a normal priority. As a result, the item will stay in the cache indefinitely, until programmatically removed or until the application terminates. To specify any extra arguments and exercise closer control on the item, use the Insert method of the Cache class instead.

The methods of the Cache class let you add, remove, and enumerate the items stored. Methods of the Cache class are listed and described in Table 18-2.

Both the Add and Insert methods don’t accept null values as the key or the value of an item to cache. If null values are used, an exception is thrown. You can configure sliding expiration for an item for no longer than one year. Otherwise, an exception will be raised. Finally, bear in mind that you cannot set both sliding and absolute expirations on the same cached item.

The Cache class inherits from Object and implements the IEnumerable interface. It is a wrapper around an internal class that acts as the true container of the stored data. The real class used to implement the ASP.NET cache varies depending on the number of affinitized CPUs. If only one CPU is available, the class is CacheSingle; otherwise, it is CacheMultiple. In both cases, items are stored in a hashtable and there will be a distinct hashtable for each CPU. It turns out that CacheMultiple manages an array of hashtables. Figure 18-1 illustrates the architecture of the Cache object.

Figure 18-1. The internal structure of the ASP.NET cache.

The hashtable is divided into two parts: public elements and private elements. In the public portion of the hashtable are placed all items visible to user applications. System-level data, on the other hand, goes in the private section. The cache is a resource extensively used by the ASP.NET runtime itself; system items, though, are neatly separated by application data and there’s no way an application can access a private element on the cache.

The Cache object is mostly a way to restrict applications to read from, and write to, the public segment of the data store. Get and set methods on internal cache classes accept a flag to denote the public attribute of the item. When called from the Cache class, these internal methods always default to the flag that selects public items.

The hashtable containing data is then enhanced and surrounded by other internal components to provide a rich set of programming features. The list includes the implementation of a least recently used (LRU) algorithm to ensure that items can be removed f the system runs short of memory, dependencies, and removal callbacks.

A cache item is characterized by a handful of attributes that can be specified as input arguments of both Add and Insert. In particular, an item stored in the ASP.NET Cache object can have the following properties:

There are basically three ways to add new items to the ASP.NET Cache object—the set accessor of the Item property, the Add method, and the Insert method. The Item property allows you to indicate only the key and the value. The Add method has only one signature that includes all the aforementioned arguments. The Insert method is the most flexible of all options and provides the following overloads:

public void Insert(String, Object);
public void Insert(String, Object, CacheDependency);
public void Insert(String, Object, CacheDependency, DateTime, TimeSpan);
public void Insert(String, Object, CacheDependency, DateTime, TimeSpan,
     CacheItemUpdateCallback);
public void Insert(String, Object, CacheDependency, DateTime, TimeSpan,
    CacheItemPriority, CacheItemRemovedCallback);

The following code snippet shows the typical call that is performed under the hood when the Item set accessor is used:

Insert(key, value, null, Cache.NoAbsoluteExpiration,
    Cache.NoSlidingExpiration, CacheItemPriority.Normal, null);

If you use the Add method to insert an item whose key matches that of an existing item, no exception is raised, nothing happens, and the method returns null.

All items marked with an expiration policy, or a dependency, are automatically removed from the cache when something happens in the system to invalidate them. To programmatically remove an item, on the other hand, you resort to the Remove method. Note that this method removes any item, including those marked with the highest level of priority (NotRemovable). The following code snippet shows how to call the Remove method:

var oldValue = Cache.Remove("MyItem");

Normally, the method returns the value just removed from the cache. However, if the specified key is not found, the method fails and null is returned, but no exception is ever raised.

When items with an associated callback function are removed from the cache, a value from the CacheItemRemovedReason enumeration is passed on to the function to justify the operation. The enumeration includes the values listed in Table 18-3.

If the item being removed is associated with a callback, the function is executed immediately after having removed the item.

Note that the CacheItemUpdateReason enumeration contains only the first two items of Table 18-3. Curiously, however, the actual numeric values behind the members in the enumeration don’t match.

Items added to the cache through the Add or Insert method can be linked to an array of files and directories as well as to an array of existing cache items, database tables, or external events. The link between the new item and its cache dependency is maintained using an instance of the CacheDependency class. The CacheDependency object can represent a single file or directory or an array of files and directories. In addition, it can also represent an array of cache keys—that is, keys of other items stored in the Cache—and other custom dependency objects to monitor—for example, database tables or external events.

The CacheDependency class has quite a long list of constructors that provide for the possibilities listed in Table 18-4.

Any change in any of the monitored objects invalidates the current item. Note that you can set a time to start monitoring for changes. By default, monitoring begins right after the item is stored in the cache. A CacheDependency object can be made dependent on another instance of the same class. In this case, any change detected on the items controlled by the separate object results in a broken dependency and the subsequent invalidation of the present item.

In the following code snippet, the item is associated with the timestamp of a file. The net effect is that any change made to the file that affects the timestamp invalidates the item, which will then be removed from the cache.

var dependency = new CacheDependency(filename);
Cache.Insert(key, value, dependency);

Bear in mind that the CacheDependency object needs to take file and directory names expressed through absolute file system paths.

Item removal is an event independent from the application’s behavior and control. The difficulty with item removal is that because the application is oblivious to what has happened, it attempts to access the removed item later and gets only a null value back. To work around this issue, you can either check for the item’s existence before access is attempted or, if you think you need to know about removal in a timely manner, register a callback and reload the item if it’s invalidated. This approach makes particularly good sense if the cached item just represents the content of a tracked file or query.

The following code demonstrates how to read the contents of a Web server’s file and cache it with a key named MyData. The item is inserted with a removal callback. The callback simply re-reads and reloads the file if the removal reason is DependencyChanged.

void Load_Click(Object sender, EventArgs e)
{
   AddFileContentsToCache("data.xml");
}

void AddFileContentsToCache(String fileName)
{
   var file = Server.MapPath(fileName);
   var reader = new StreamReader(file);
   var data = reader.ReadToEnd();
   reader.Close();
   CreateAndCacheItem(data, file);

   // Display the contents through the UI
   contents.Text = Cache["MyData"].ToString();
}

void CreateAndCacheItem(Object data, String file)
{
   var removal = new CacheItemRemovedCallback(ReloadItemRemoved);
   var dependency = new CacheDependency(file);
   Cache.Insert("MyData", data, dependency, Cache.NoAbsoluteExpiration,
         Cache.NoSlidingExpiration, CacheItemPriority.Normal, removal);
}

void ReloadItemRemoved(String key, Object value,
       CacheItemRemovedReason reason)
{
   if (reason == CacheItemRemovedReason.DependencyChanged)
   {
      // At this time, the item has been removed. We get fresh data and
      // re-insert the item
      if (key == "MyData")
         AddFileContentsToCache("data.xml");

      // This code runs asynchronously with respect to the application,
      // as soon as the dependency gets broken. To test it, add some
      // code here to trace the event
   }
}

If the underlying file has changed, the dependency-changed event is notified and the new contents are automatically loaded. So the next time you read from the cache, you get fresh data. If the cached item is removed, any successive attempt to read returns null. Here’s some code that shows you how to read from the cache and remove a given item:

void Read_Click(Object sender, EventArgs e)
{
   var data = Cache["MyData"];
   if (data == null)
   {
       contents.Text = "[No data available]";
       return;
   }

   // Update the UI
   contents.Text = (String) data;
}

void Remove_Click(Object sender, EventArgs e)
{
    Cache.Remove("MyData");
}

Note that the item removal callback is a piece of code defined by a user page but automatically run by the Cache object as soon as the removal event is fired. The code contained in the removal callback runs asynchronously with respect to the page. If the removal event is related to a broken dependency, the Cache object executes the callback as soon as the notification is detected.

If you add an object to the Cache and make it dependent on a file, directory, or key that doesn’t exist, the item is regularly cached and marked with a dependency as usual. If the file, directory, or key is created later, the dependency is broken and the cached item is invalidated. In other words, if the dependency item doesn’t exist, it’s virtually created with a null timestamp or empty content.

Each item in the cache is given a priority—that is, a value picked up from the CacheItemPriority enumeration. A priority is a value ranging from Low (lowest) to NotRemovable (highest), with the default set to Normal. The priority is supposed to determine the importance of the item for the Cache object. The higher the priority is, the more chances the item has to stay in memory even when the system resources are going dangerously down.

If you want to give a particular priority level to an item being added to the cache, you have to use either the Add or Insert method. The priority can be any value listed in Table 18-5.

The Cache object is designed with two goals in mind. First, it has to be efficient and built for easy programmatic access to the global repository of application data. Second, it has to be smart enough to detect when the system is running low on memory resources and to clear elements to free memory. This trait clearly differentiates the Cache object from HttpApplicationState, which maintains its objects until the end of the application (unless the application itself frees those items). The technique used to eliminate low-priority and seldom-used objects is known as scavenging.

Priority level and changed dependencies are two of the factors that can lead a cached item to be automatically garbage-collected from the Cache. Another possible cause for a premature removal from the Cache is infrequent use associated with an expiration policy. By default, all items added to the cache have no expiration date, neither absolute nor relative. If you add items by using either the Add or Insert method, you can choose between two mutually exclusive expiration policies: absolute expiration and sliding expiration.

Absolute expiration is when a cached item is associated with a DateTime value and is removed from the cache as the specified time is reached. The DateTime.MaxValue field, and its more general alias NoAbsoluteExpiration, can be used to indicate the last date value supported by the .NET Framework and to subsequently indicate that the item will never expire.

Sliding expiration implements a sort of relative expiration policy. The idea is that the object expires after a certain interval. In this case, though, the interval is automatically renewed after each access to the item. Sliding expiration is rendered through a TimeSpan object—a type that in the .NET Framework represents an interval of time. The TimeSpan.Zero field represents the empty interval and is also the value associated with the NoSlidingExpiration static field on the Cache class. When you cache an item with a sliding expiration of 10 minutes, you use the following code:

Insert(key, value, null, Cache.NoAbsoluteExpiration,
    TimeSpan.FromMinutes(10), CacheItemPriority.Normal, null);

Internally, the item is cached with an absolute expiration date given by the current time plus the specified TimeSpan value. In light of this, the preceding code could have been rewritten as follows:

Insert(key, value, null, DateTime.Now.AddMinutes(10),
    Cache.NoSlidingExpiration, CacheItemPriority.Normal, null);

However, a subtle difference still exists between the two code snippets. In the former case—that is, when sliding expiration is explicitly turned on—each access to the item resets the absolute expiration date to the time of the last access plus the time span. In the latter case, because sliding expiration is explicitly turned off, any access to the item doesn’t change the absolute expiration time.

There’s just one possible answer to this question—it depends. It depends on the characteristics of the application and the expected goals. For an application that must optimize throughput and serve requests in the shortest possible amount of time, caching is essential. The quantity of data you cache and the amount of time you cache it in are the two parameters you need to play with to arrive at a good solution.

Caching is about reusing data, so data that is not often used in the lifetime of the application is not a good candidate for the cache. In addition to being frequently used, cacheable data is also general-purpose data rather than data that is specific to a request or a session. If your application manages data with these characteristics, cache it with no fear.

Caching is about memory, and memory is relatively cheap. However, a bad application design can easily drive the application to unpleasant out-of-memory errors regardless of the cost of a memory chip. On the other hand, caching can boost the performance just enough to ease your pain and give you more time to devise a serious refactoring.

Sometimes you face users who claim to have an absolute need for live data. Sure, data parked in the cache is static, unaffected by concurrent events, and not fully participating in the life of the application. Can your users afford data that has not been updated for a few seconds? With a few exceptions, the answer is, “Sure, they can.” In a canonical Web application, there’s virtually no data that can’t be cached at least for a second or two. No matter what end users claim, caching can realistically be applied to the vast majority of scenarios. Real-time systems and systems with a high degree of concurrency (for example, a booking application) are certainly an exception, but most of the time a slight delay of one or two seconds can make the application run faster under stress conditions without affecting the quality of the service.

In the end, you should be considering caching all the time and filter it out in favor of direct data access only in special situations. As a practical rule, when users claim they need live data, you should try to provide a counterexample that proves to them that a few seconds of delay are still acceptable and that the delay can maximize hardware and software investments.

Fetching the real data is an option, but it might be the most expensive one. If you choose that option, make sure you really need it. Accessing cached data is usually faster if the data you get in this way makes sense to the application. On the other hand, be aware that caching requires memory. If abused, it can lead to out-of-memory errors and performance hits. Having said that, don’t be too surprised if you find out that sometimes fetching data is actually faster than accessing items in a busy cache. This is due to how optimized SQL Server access has gotten these days.

As mentioned, no data stored in the ASP.NET cache is guaranteed to stay there when a piece of code attempts to read it. For the safety of the application, you should never rely on the value returned by the Get method or the Item property. The following pattern keeps you on the safe side:

var data =  Cache["MyData"];
if (data != null)
{
   // The data is here, process it
   ...
}

The code snippet deliberately omits the else branch. What should you do if the requested item is null? You can abort the ongoing operation and display a friendly message to the user, or you can perhaps reload the data with a new fetch. Whatever approach you opt for, it will hardly fit for just any piece of data you can have in the cache.

If you need the cache as a structural part of the application (rather than just for caching only a few individual pieces of data), it has to be strictly related to the data access layer (DAL) and the repository interfaces you have on top of that. (See Chapter 14.) Depending on the pattern you prefer, you can have caching implemented as a service in the business tier (Cache-side pattern) or integrated in the DAL and transparent to the rest of the application (Cache Through pattern). Figure 18-2 shows the resulting architecture in both cases.

Figure 18-2. Isolating the caching layer.

In addition, you need to consider the pluggability of the caching layer. Whether you design it as an application service or as an integral part of the DAL, the caching service must be abstracted to an interface so that it can be injected in the application or in the DAL. At a minimum, the abstraction will offer the following:

public interface ICacheService
{
    Object Get(String key);
    void Set(String key, Object data);
    ...
}

You are responsible for adding dependencies and priorities as appropriate. Here’s the skeleton of a class that implements the interface using the native ASP.NET Cache object:

public class AspNetCacheService : ICacheService
{
   public Object Get(String key)
   {
       return HttpContext.Current.Cache[key];
   }
   public void Set(String key, Object data)
   {
       HttpContext.Current.Cache[key] = data;
   }
   ...
}

As emphatic as it might sound, you should never use the Cache object directly from code-behind classes in a well-designed, ASP.NET-based layered solution.

The .NET Framework provides no method on the Cache class to programmatically clear all the content. The following code snippet shows how to build one:

public void Clear()
{
    foreach(DictionaryEntry elem in Cache)
    {
        string s = elem.Key.ToString();
        Cache.Remove(s);
    }
}

Even though the ASP.NET cache is implemented to maintain a neat separation between the application’s items and the system’s items, it is preferable that you delete items in the cache individually. If you have several items to maintain, you might want to build your own wrapper class and expose one single method to clear all the cached data.

Whenever you read or write an individual cache item, from a threading perspective you’re absolutely safe. The ASP.NET Cache object guarantees that no other concurrently running threads can ever interfere with what you’re doing. If you need to ensure that multiple operations on the Cache object occur atomically, that’s a different story. Consider the following code snippet:

var counter = -1;
object o = Cache["Counter"];
if (o == null)
{
    // Retrieve the last good known value from a database
    // or return a default value
    counter = RetrieveLastKnownValue();
}
else
{
    counter = (Int32) Cache["Counter"];
    counter ++;
    Cache["Counter"] = counter;
}

The Cache object is accessed repeatedly in the context of an atomic operation—incrementing a counter. Although individual accesses to Cache are thread-safe, there’s no guarantee that other threads won’t kick in between the various calls. If there’s potential contention on the cached value, you should consider using additional locking constructs, such as the C# lock statement (SyncLock in Microsoft Visual Basic .NET).

lock(yourSynchronizer) {
    // Access the Cache here. This pattern must be replicated for
    // each access to the cache that requires serialization.
}

Although you normally tend to cache only global data and data of general interest, to squeeze out every little bit of performance you can also cache per-request data that is long-lived even though it’s used only by a particular page. You place this information in the Cache object.

Another form of per-request caching is possible to improve performance. Working information shared by all controls and components participating in the processing of a request can be stored in a global container for the duration of the request. In this case, though, you might want to use the Items collection on the HttpContext class (discussed in Chapter 16) to park the data because it is automatically freed up at the end of the request and doesn’t involve implicit or explicit locking like Cache.

To fully support derived classes and to facilitate their integration into the ASP.NET caching infrastructure, a bunch of new public and protected members have been added to the CacheDependency class. They are summarized in Table 18-6.

As mentioned, a custom dependency class relies on its parent for any interaction with the Cache object. The NotifyDependencyChanged method is called by classes that inherit CacheDependency to tell the base class that the dependent item has changed. In response, the base class updates the values of the HasChanged and UtcLastModified properties. Any cleanup code needed when the custom cache dependency object is dismissed should go into the DependencyDispose method.

As you might have noticed, nothing in the public interface of the base CacheDependency class allows you to insert code to check whether a given condition—the heart of the dependency—is met. Why is this? The CacheDependency class was designed to support only a limited set of well-known dependencies—against files, time, and other cached items.

To detect file changes, the CacheDependency object internally sets up a file monitor object and receives a call from it whenever the monitored file or directory changes. The CacheDependency class creates a FileSystemWatcher object and passes it an event handler. A similar approach is used to establish a programmatic link between the CacheDependency object and the Cache object and its items. The Cache object invokes a CacheDependency internal method when one of the monitored items changes. What does this all mean to the developer?

A custom dependency object must be able to receive notifications from the external data source it is monitoring. In most cases, this is really complicated if you can’t bind to existing notification mechanisms (such as file system monitor or SQL Server notifications). When the notification of a change in the source is detected, the dependency uses the parent’s infrastructure to notify the cache of the event. We’ll consider a practical example in a moment.

Not only can you create a single dependency on an entry, you can also aggregate dependencies. For example, you can make a cache entry dependent on both a disk file and a SQL Server table. The following code snippet shows how to create a cache entry, named MyData, that is dependent on two different files:

// Creates an array of CacheDependency objects
CacheDependency dep1 = new CacheDependency(fileName1);
CacheDependency dep2 = new CacheDependency(fileName2);
CacheDependency deps[] = {dep1, dep2};

// Creates an aggregate object
AggregateCacheDependency aggDep = new AggregateCacheDependency();
aggDep.Add(deps);
Cache.Insert("MyData", data, aggDep)

Any custom cache dependency object (including SqlCacheDependency) inherits CacheDependency, so the array of dependencies can contain virtually any type of dependency.

The AggregateCacheDependency class is built as a custom cache dependency object and inherits the base CacheDependency class.

To better understand the concept of custom dependencies, think of the following example. You need to cache the inner text of a particular node in an XML file. You can define a custom dependency class that caches the current value upon instantiation and reads the file periodically to detect changes. When a change is detected, the cached item bound to the dependency is invalidated.

A good way to poll a local or remote resource is through a timer callback. Let’s break the procedure into a few steps:

There’s no need for the developer to specify details about how the cache dependency is broken or set up. The CacheDependency class takes care of it entirely.

The following source code shows the core implementation of the custom XmlDataCacheDependency class:

public class XmlDataCacheDependency : CacheDependency
{
    // Internal members
    static Timer _timer;
    Int32 _pollSecs = 10;
    String _fileName;
    String _xpathExpression;
    String _currentValue;

   public XmlDataCacheDependency(String file, String xpath, Int32 pollTime)
   {
      // Set internal members
      _fileName = file;
      _xpathExpression = xpath;
      _pollSecs = pollTime;

      // Get the current value
      _currentValue = CheckFile();

      // Set the timer
      if (_timer == null) {
         var ms = _pollSecs * 1000;
         var cb = new TimerCallback(XmlDataCallback);
         _timer = new Timer(cb, this, ms, ms);
      }
   }

   public String CurrentValue
   {
      get { return _currentValue; }
   }

   public void XmlDataCallback(Object sender)
   {
      // Get a reference to THIS dependency object
      var dep = sender as XmlDataCacheDependency;

      // Check for changes and notify the base class if any are found
      var value = CheckFile();
      if (!String.Equals(_currentValue, value))
          dep.NotifyDependencyChanged(dep, EventArgs.Empty);
   }

   public String CheckFile()
   {
      // Evaluates the XPath expression in the file
      var doc = new XmlDocument();
      doc.Load(_fileName);
      var node = doc.SelectSingleNode(_xpathExpression);

      return node.InnerText;
   }

   protected override void DependencyDispose()
   {
      // Kill the timer and then proceed as usual
      _timer.Dispose();
      _timer = null;
      base.DependencyDispose();
   }
}

When the cache dependency is created, the file is parsed and the value of the XPath expression is stored in an internal member. At the same time, a timer is started to repeat the operation at regular intervals. The return value is compared to the value stored in the constructor code. If the two are different, the NotifyDependencyChanged method is invoked on the base CacheDependency class to invalidate the linked content in the ASP.NET Cache.

How can you use this dependency class in a Web application? It’s as easy as it seems—you just use it in any scenario where a CacheDependency object is acceptable. For example, you create an instance of the class in the Page_Load event and pass it to the Cache.Insert method:

protected const String CacheKeyName = "MyData";
protected void Page_Load(Object sender, EventArgs e)
{
   if (!IsPostBack)
   {
      // Create a new entry with a custom dependency (and poll every 10 seconds)
      var dependency = new XmlDataCacheDependency(
          Server.MapPath("employees.xml"),
          "MyDataSet/NorthwindEmployees/Employee[employeeid=3]/lastname",
          10);
      Cache.Insert(CacheKeyName, dependency.CurrentValue, dependency);
   }

   // Refresh the UI
   Msg.Text = Display();
}

You write the rest of the page as usual, paying close attention to accessing the specified Cache key. The reason for this is that because of the dependency, the key could be null. Here’s an example:

protected String Display()
{
    var o = Cache[CacheKeyName];
    return o ?? "[No data available--dependency broken]";
}

The XmlDataCacheDependency object allows you to control changes that occur on a file and decide which are relevant and might require you to invalidate the cache. The sample dependency uses XPath expressions to identify a subset of nodes to monitor for changes.

The SqlCacheDependency class has two constructors. The first takes a SqlCommand object, and the second accepts two strings: the database name and the table name. The following code creates a SQL Server dependency and binds it to a cache key:

protected void AddToCache(Object data)
{
    var database = "Northwind";
    var table = "Customers";
    var dependency = new SqlCacheDependency(database, table);
    Cache.Insert("MyData", data, dependency);
}
protected void Page_Load(Object sender, EventArgs e)
{
    if (!IsPostBack)
    {
        // Get some data to cache
        var data = Customers.LoadByCountry("USA");

        // Cache with a dependency on Customers
        AddToCache(data);
    }
}

The data in the cache can be linked to any data-bound control, as follows:

var data = Cache["MyData"] as IList<Customer>;
if (data == null)
    Trace.Warn("Null data");

CustomerList.DataTextField = "CompanyName";
CustomerList.DataSource = data;
CustomerList.DataBind();

When the database is updated, the MyData entry is invalidated and, as in the sample implementation provided here, the list box displays empty.

SELECT * FROM customers WHERE country='USA'

Commonly based on a cluster of cache servers, distributed cache gains scalability through the addition of new servers and high availability (H/A) through replication of the content on each server. If one cache server goes down, no data is lost because another copy on another server is immediately available to the application.

Although high availability remains a natural attribute of a distributed caching system, the real effectiveness of replication has to be measured against the real behavior of the application. Replication is great for applications that do a lot of reads. As you add more servers, you add more read capacity to your cache cluster and improve the responsiveness and availability of the application.

At the same time, a heavily replicated cache is not desirable for write-intensive applications. If the application updates the cache frequently, maintaining multiple synchronized copies of the data becomes ineffective.

The topology of the distributed cache plays an important role in determining its success. There are two main topologies: the replicated cache and the partitioned cache.

In a replicated cache topology, the various servers in the cluster hold a private copy of the data. In this way, the reliability is high and users never experience loss of data, even when a server goes down. This cache topology is excellent for read-intensive apps, but it turns into overhead for write-intensive applications.

In a partitioned cache topology, the entire content of the cache is partitioned among the various servers. This design represents a good compromise between availability and performance. This is the first option to consider in scenarios where read/write operations are balanced.

A popular variation of this topology privileges high availability and is often referred to as partitioned cache with H/A. In this case, each partition is also replicated and servers contain their regular data partition plus a copy of another partition.

A distributed caching system is not necessarily limited to just one tier. It can be complemented with a client cache that lives close to the user and keeps in-process a copy of frequently used data from the cache. When used, such a client cache is usually read-only and not kept in sync with the rest of the caching system.

By design, the cache is a place for temporary information that needs be replaced periodically with up-to-date data. Of high importance in the feature list of a distributed cache is the ability to specify how long data should stay in the cache. Common expiration policies are based on an absolute time (for example, “Remove items at noon or in one hour”) or a sliding usage time (for example, “Remove items if not used for a given period”).

Most distributed caches are in-memory and do not persist their content to disk. So in most situations, memory is limited and the cache size cannot grow beyond a certain fixed limit. When the cache reaches this size, it should start removing cached items to make room for new ones, a process usually referred to as performing evictions. Least recently used (LRU) and least frequently used (LFU) are the two most popular algorithms for data eviction.

Cache dependencies, both on other cached items and external resources, are also desirable features to have in a distributed cache. Especially when you have domain data in the cache, you might want to search for data using a more flexible approach than using a simple key. Ideally, a LINQ-based query language for cached items is a big plus.

Finally, read-through and write-through (or write-behind) capabilities qualify a caching solution as a top-quality solution. Read-through capabilities refer to the cache’s ability to automatically read data from a configured data store in case of a cache miss.

Write-through capabilities, instead, enable the cache to automatically write data to the configured data store whenever you update the cache. In other words, the cache, not your application, holds the key to the data access layer. The difference between write-through and write-behind capabilities is that in the former case the application waits until both the cache and data store are updated. In write-behind (or write-back) mode, the application updates the cache synchronously but then the cache ripples changes to the database in an asynchronous manner.

This is a list of the features one would reasonably expect from a distributed cache. Not all products available today, however, offer these features to the same extent. Let’s see what the Microsoft distributed caching service currently offers.

AppFabric Caching Services (ACS) is an out-of-process cache that combines a simple programming interface with a clustered architecture. ACS should not be viewed as a mere (distributed) replacement for the native ASP.NET Cache object. When you have a very slow data access layer that assembles data from various sources (for example, relational databases, SAP, mainframes, and documents) and when you have an application deployed on a Web farm, you definitely need a caching layer to mediate access to data and distribute the load of data retrieval on an array of servers.

The plain old Cache object of ASP.NET is simply inadequate and, in similar scenarios, you are encouraged to use ACS in lieu of Cache. Keep in mind, however, that although endowed with a similar programming interface, ACS currently lacks some of the more advanced capabilities of the ASP.NET Cache, such as dependencies, sliding and absolute expiration, and removal callbacks. At the same time, it remains as simple to use as a hashtable, offers a scalable and reliable infrastructure, is configurable via Windows PowerShell, and presents some developer-oriented features that are not in ASP.NET, such as programmatic access to cache-related properties of cached items (such as priority or expiration) and event propagation (such as notifying client apps of changed items).

ACS is articulated in two levels: the client cache and distributed cache. The client cache is a component to install on the Web server machine and represents the gateway used by ASP.NET applications to read and write through ACS. The distributed cache includes some cache server machines that are each running an instance of the AppFabric Caching Services and storing data according to the configured topology. In addition, the client cache can optionally implement a local, server-specific cache that makes access to selected data even faster. The data found in this local cache is not kept in sync with the data in the cluster. Figure 18-4 provides an overall vision of AppFabric Caching Services.

Figure 18-4. Architecture of AppFabric Caching Services.

The configuration script for the servers in the cache cluster contains the name of the cluster and general settings such as topology and data eviction policies. In addition, the configuration contains the list of servers and relative names and ports. Each service is configured to use two main ports: one to communicate with the client (cachePort) and one to communicate their availability to neighbors (clusterPort). Configuration information for the cluster is saved in one location, which can be an XML file on a shared network folder, a SQL Server database, or a custom store. Here’s an example excerpted from an XML file (clusterconfig.xml):

<configuration>
    <configSections>
        <section name="dataCache"
                 type="Microsoft.ApplicationServer.Caching.DataCacheSection,
                       Microsoft.ApplicationServer.Caching.Core, ..." />
    </configSections>
    <dataCache size="Small">
        <hosts>
            <host replicationPort="22236"
                  arbitrationPort="22235"
                  clusterPort="22234"
                  hostId="879796007"
                  size="1007"
                  leadHost="true"
                  account="My-LaptopDinoE"
                  cacheHostName="AppFabricCachingService"
                  name="My-Laptop"
                  cachePort="22233" />
        </hosts>
    </dataCache>
</configuration>

Each server can have one or multiple caches of data. A data cache is simply a logical way of grouping data. Each enabled server has one default data cache (which is unnamed), but you are allowed to create your own. Data caches can be individually configured.

Each data cache is optionally made of regions. A region is a logical way of grouping data within a given data cache. Each region is defined programmatically on a given server and, unlike data caches, they do not span multiple servers. Finally, you have cached objects. A cached object is simply the data you store either directly in the data cache or in a region. Figure 18-5 provides an illustration.

Figure 18-5. Data caches and regions.

In Figure 18-5, you see that named and unnamed caches can span multiple servers, whereas optional regions are specific to just one server and are usually created via Windows PowerShell. As a developer, you are not interested in the location of a region; you only need to know whether it exists and what data it contains. In this way, you can provide more information to ACS and make it return data more quickly.

To use ACS in your ASP.NET pages, you need to configure the Web server environment first. This requires adding a section to the application’s web.config file. Here’s a snippet:

<dataCacheClient>
   <localCache isEnabled="false" />
     <hosts>
       <host name="Server01" cachePort="22233" />
       ...
     </hosts>
</dataCacheClient>

Obviously, you must first have available a bunch of AppFabric assemblies on the Web server so that you can safely declare the new dataCacheClient section in the configuration. For some reason, the ACS assemblies don’t show up in the Microsoft Visual Studio list of available assemblies and you have to catch them yourself in the folds of the %System%AppFabric directory. You need to pick up two assemblies: Microsoft.ApplicationServer.Caching.Core and Microsoft.ApplicationServer.Caching.Client.

<configuration>
   <configSections>
       <section name="dataCacheClient"
                type="Microsoft.ApplicationServer.Caching.DataCacheClientSection,
                      Microsoft.ApplicationServer.Caching.Core"
                 allowLocation="true"
                 allowDefinition="Everywhere" />
    </configSections>
    ...
</configuration>

The dataCacheClient section specifies the desired deployment type, the list of hosts that provide cache data, and any optional settings regarding the local cache.

An ACS client can connect to all listed hosts. The ACS infrastructure tracks the placement of cached objects across all hosts and routes your client straight to the right host when a request for a particular cached object is made.

If you enable the local cache, any retrieved objects are saved in a local cache within the ACS client, thus forming an additional layer of virtual memory. The local cache takes precedence over data in the cluster. Note that ACS performs no automatic checks on data in the cluster to detect possible recent changes that occurred for the objects in the local cache. In other words, by using the local cache you trade speed of data retrieval for data accuracy.

Let’s look at some sample code. The entry point in ACS is the cache factory object. The factory, then, will gain you access to any data cache available in the system. The simplest way to get a factory is shown here:

var factory = new DataCacheFactory();

The factory needs to consume some information to be successfully instantiated. You can provide configuration settings as a constructor parameter or let the class figure it out itself from the configuration file. Here’s the fluent code you can use to initialize the factory without using the web.config file:

var servers = new List<DataCacheServerEndpoint>(1)
              {
                 new DataCacheServerEndpoint("Server01", 22233)
              };
var configuration = new DataCacheFactoryConfiguration
                    {
                        Servers = servers,
                        LocalCacheProperties = new DataCacheLocalCacheProperties()
                    };
var factory = new DataCacheFactory(configuration);

The next steps are straightforward. First, you get a data cache and then you start reading and writing data to it. A data cache must be created administratively using the Windows PowerShell console. Here’s the command you need to create a named cache. (As mentioned, you use the name default to create the default unnamed cache.)

New-Cache -cachename yourCache

In this way, you get a named cache with the same default settings as the default unnamed cache. Of course, you can express additional parameters on the command line. For example, the following line creates a cache with no eviction policy enabled:

New-Cache -cachename yourCache -eviction:none

To get command line information, you can type the following:

New-Cache -?

If the requested cache is not available, the constructor of DataCacheFactory just throws an exception:

var factory = new DataCacheFactory();
var dinoCache = factory.GetCache("Dino");
var defaultCache = factory.GetDefaultCache();

From this point on, you can use the object returned by GetCache and GetDefaultCache in much the same way you would use the native Cache object of ASP.NET. With just a little difference, you now can access information stored across a (expansible) cluster of servers:

dinoCache[key] = value;

Of course, you might want to call the factory and get cache objects only once in the application, preferably at startup. Unlike to the ASP.NET Cache, you don’t have dependencies, but you do have regions, search capabilities, and a rich event model (through which you can simulate some of the ASP.NET cache dependencies).

Memcached (http://memcached.org) is a popular, open-source distributed cache widely used by some popular social networks. Facebook is the most illustrious example. Technically speaking, Memcached can be hosted on a number of platforms, including Windows. Memcached, however, was originally created for Unix-based machines. For this reason, it’s often associated with PHP and, in general, with the LAMP stack (where LAMP stands for Linux, Apache, MySQL, and PHP/Python/Perl).

Memcached runs as a background service on a variety of servers and communicates with the outside world through a configured port (usually port 11211). Client applications employ ad hoc libraries to contact a Memcached-equipped server and read or write data. A client can connect to any available servers; servers, on the other hand, are isolated from one another. The server stores data in memory and applies an eviction policy when it runs short of RAM.

A .NET library that can be used to talk to a Memcached installation (regardless of the host environment) can be found at http://sourceforge.net/projects/memcacheddotnet.

Written in C# and entirely based on .NET managed code, SharedCache (sharedcache.com) is another open-source distributed and replicated cache for use in server farms. SharedCache supports three deployment scenarios: a partitioned cache, a replicated cache, and a single instance.

With a partitioned cache, the entire data set is split across the active servers that form the cluster of cache server machines. With a replicated cache, each cache server contains the entire data set. In this case, the runtime infrastructure is responsible for keeping data over the servers in sync. Finally, the single instance mode entails you having a single cache server but host it out of process with respect to the client Web application. Moving from one configuration to another doesn’t require code refactoring; it’s simply a matter of configuration.

With good products available for free or under open-source licenses, why should you ever consider commercial solutions, then? The answer is simple: commercial solutions offer more advanced features, capabilities and, especially, support. At their core, both commercial and free solutions provide a fast and scalable caching layer; the difference is in the extras that are provided. If you’re OK with the core features you get from ACS or the community edition of Memcached, by all means stick to that. Otherwise, be ready to spend some good money for the extras. Table 18-7 lists a few products currently available.

First and foremost, browsers won’t save any responses that explicitly prohibit the use of the cache. Furthermore, browsers won’t save any responses that come from a secure channel (HTTPS) or that require authentication.

If the requested URL doesn’t have a match in the local cache, the browser just sends the request on to the server. Otherwise, if a match is found, the browser checks whether the cached representation of the requested resource is still valid. A valid representation is a representation that has not expired. Valid representations (also referred to as fresh representations) are served directly from the cache without any contact with the server.

The browser uses HTTP headers to determine whether the representation is fresh or stale. The Expires HTTP header indicates the absolute expiration date of the resource. The max-age HTTP header indicates for how long the representation is fresh. If the resource is stale, the browser will ask the origin server to validate the representation. If the server replies that a newer resource exists, a new request is made. Otherwise, the saved representation is served.

These simple rules express the behavior of Web caches—both browser cache and proxy cache. If ASP.NET pages and JavaScript files behave differently, the difference is all in the HTTP headers that accompany them.

An ASP.NET page is a dynamic resource, meaning that its content might be different even when the requesting URL is the same. This structural attribute makes an ASP.NET page a noncacheable resource. An image that represents a company’s logo or a script file, on the other hand, is a much more static type of resource and is inherently more cacheable.

By default, an ASP.NET page is cacheable by browsers but not by proxy servers. However, an ASP.NET page has no expiration set and subsequently is always stale. For this reason, any request you make for an ASPX resource will always result in an immediate refetch from the server as if the page was never cached. Figure 18-6 shows this.

Figure 18-6. ASPX pages are always fetched from the server.

The screen shot shows that default.aspx is requested as usual, whereas cascading style sheets (CSS), images, and scripts are checked and served from the local cache because they are not modified.

The default behavior of the ASP.NET page results from a similar payload and especially from the Cache-Control header.

Cache-Control       private
Content-Type        text/html; charset=utf-8
Server              Microsoft-IIS/7.5
X-AspNet-Version    4.0.30319
X-Powered-By        ASP.NET
Date                Thu, 02 Dec 2010 17:56:06 GMT
Content-Length      12315

You can change at will the caching settings for any ASPX page. One of the tools you can use for doing so is the @OutputCache directive that I’ll cover in just a moment.

Typically, static resources are served with a relatively long lifetime, with the goal of staying in the cache as much as possible. Obviously, developers as well as Web masters are ultimately responsible for deciding about the maximum age allowed for a given set of resources. For static resources, you can set HTTP headers from the Web server (for example, IIS) management console. (See Figure 18-7.)

Figure 18-7. Typical response headers for a static resource.

The figure shows the response headers of a JPEG file, which is given about a month of life in the browser cache. Modern Web servers add an ETag header, which represents a hash calculated on the content of the resource. They also include the Last-Modified header with the timestamp of the server resource. When the resource gets stale and both the ETag header and timestamp match, you can be really sure that the resource is still the same.

Just like other page directives, @OutputCache goes at the top of the ASP.NET page. The directive allows you to specify a handful of attributes, a couple of which—Duration and VaryByParam—are mandatory. The Duration attribute indicates in seconds how long the page output should stay in the cache. The VaryByParam attribute allows you to vary the cached output depending on the GET query string or form POST parameters. The following declaration indicates the page should stay in the cache for one minute regardless of any GET or POST parameters:

<%@ OutputCache Duration="60" VaryByParam="None" %>

For frequently requested pages and relatively static pages, the @OutputCache directive is a real performance booster. With a shorter duration, even limited to one second or two, it provides a way to speed up the entire application.

Available attributes indicate the location of the cache, its duration, and the arguments to use to vary page caching. The list of supported attributes is shown in Table 18-8. Note that the directive can be applied to both pages (.aspx) and user controls (.ascx). Note that some of the attributes are valid in one case but not the other.

Note that the VaryByParam attribute is mandatory. If you omit it, a runtime exception is always thrown. However, if you don’t need to vary by parameters, set the attribute to None. The empty string is not an acceptable value for the VaryByParam attribute.

Among other things, you use the @OutputCache directive to decide where the page output should be cached. In general, it can go in three different locations, one not necessarily excluding the other. The page can be cached on the client (the browser cache), on the IIS Web server, and even by an intermediate proxy server. The various options are listed in Table 18-9. They come from the OutputCacheLocation enumerated type.

When the cache-control header is public, ASP.NET also emits the header max-age set to the same value as the duration attribute. Expires and max-age play the same role except that the former requires an absolute date and time (that has to be parsed by browsers and proxies), whereas the latter just indicates the number of seconds to wait. In general, when both Expires and max-age are specified, max-age wins.

The value of No-Cache assigned to the cache-control HTTP header instructs the browser to check with the server as to the freshness of the page before serving it. However, in combination with Expires set to –1, it indicates that the page is stale and subsequently needs be refetched. The net effect is the same as if the page was never cached. The No-Store value, on the other hand, instructs the browser not to save the resource locally. If the page comes over HTTPS, however, it will never be cached locally.

In addition to browser and proxy caches, I mentioned server-side caching. I’ll return to that in a moment; for now, it suffices to say that it is yet another level of page-output caching specific to ASP.NET. A special component—the page output provider—will capture the output of a page and cache it somewhere on the server. The default provider caches pages inside the ASP.NET Cache object in the memory space of the worker process (and machine) that is currently serving the request. As you can see, this solution is not ideal if you have a Web farm where there’s no guarantee that subsequent requests for the same page are served by the same machine. If you’re running a Web farm, you might want to consider replacing the default provider with the output cache provider made available by the AppFabric Caching Services.

When the output caching service is active on a page, the Duration attribute indicates the number of seconds that the caching system will maintain an HTML-compiled version of the page. Next, requests for the same page, or for an existing parameterized version of the page, will be serviced while bypassing most of the ASP.NET pipeline. As mentioned, this process has two important repercussions—no authentication is possible and no code is run, meaning that no page events are fired and handled and no state is updated.

A fair value for the Duration attribute depends on the application. It can be a few days or a few hours if the page doesn’t need to be updated frequently. In general, a short duration (say, just a few seconds) can always be useful also for applications that claim live data all the time.

In IIS 6 and newer versions, you have the possibility of telling IIS to cache the page output for you without involving the ASP.NET runtime. This feature has tremendous potential and can dramatically improve the performance of a Web server, as long as enough of the content being served is cacheable.

The great news for ASP.NET developers is that no code changes are required to benefit from kernel caching, except for the @OutputCache directive. You enable kernel caching administratively from within the IIS Manager. When both output caching and IIS kernel caching are enabled, a kernel-level driver in IIS intercepts any incoming requests and, if the response was previously cached, it serves them by directly flushing the cached data from wherever the output provider in use had stored it. As this happens at the kernel level, there’s no need to make any context switch to user mode, which results in a remarkable performance improvement—about one tenth of the time it would take in classic user mode.

On a high-volume Web site, an output cache duration of only a few seconds can make a huge difference for the overall throughput of a Web server. There’s more to know about kernel caching, though. First and foremost, kernel caching is available only for pages requested through a GET verb. No kernel caching is possible on postbacks. Furthermore, pages with VaryByParam and VaryByHeader attributes set are also not stored in the kernel cache. Finally, note that ASP.NET Request/Cache performance counters will not be updated for pages served by the kernel cache.

The SqlDependency attribute is the @OutputCache directive’s interface to the SqlCacheDependency class that we discussed earlier. When the SqlDependency attribute is set to a Database:Table string, a SQL Server cache dependency object is created. When the dependency is broken, the page output is invalidated and the next request will be served by pushing the request through the pipeline as usual. The output generated will be cached again.

<% @OutputCache Duration="15" VaryByParam="none"
                SqlDependency="Northwind:Employees" %>

A page that contains this code snippet has its output cached for 15 seconds or until a record changes in the Employees table in the Northwind database. Note that the Northwind string here is not the name of a database—it’s the name of an entry in the <databases> section of the configuration file. That entry contains detailed information about the connection string to use to reach the database. You can specify multiple dependencies by separating multiple Database:Table pairs with a semicolon in the value of the SqlDependency attribute.

Table 18-10 shows the properties of the HttpCachePolicy class.

When a cached page has several vary-by headers or parameters, a separate version of the page is available for each HTTP header type or parameter name.

Table 18-11 shows the methods of the HttpCachePolicy class.

Most methods of the HttpCachePolicy class let you control the values of some HTTP headers that relate to the browser cache. The AddValidationCallback method, on the other hand, provides a mechanism to programmatically check the validity of page output in the server cache before it is returned from the cache.

Before the response is served from the ASP.NET cache, all registered handlers are given a chance to verify the validity of the cached page. If at least one handler marks the cached page as invalid, the entry is removed from the cache and the request is served as if it were never cached. The signature of the callback function looks like this:

public delegate void HttpCacheValidateHandler(
    HttpContext context,
    Object data,
    ref HttpValidationStatus validationStatus
);

The first argument denotes the context of the current request, whereas the second argument is any user-defined data the application needs to pass to the handler. Finally, the third argument is a reference to a value from the HttpValidationStatus enumeration. The callback sets this value to indicate the result of the validation. Acceptable values are IgnoreThisRequest, Invalid, and Valid. In the case of IgnoreThisRequest, the cached resource is not invalidated but the request is served as if no response was ever cached. If the return value is Invalid, the cached page is not used and gets invalidated. Finally, if the return value is Valid, the cached response is used to serve the request.

To vary output caching by parameters, you can use either the VaryByParam attribute of the @OutputCache directive or the VaryByParams property on the HttpCachePolicy class. If you proceed declaratively, use the following syntax:

<% @OutputCache Duration="60" VaryByParam="employeeID" %>

Note that the VaryByParam attribute is mandatory; if you don’t want to specify a parameter to vary cached content, set the value to None. If you want to vary the output by all parameters, set the attribute to an asterisk (*). When the VaryByParam attribute is set to multiple parameters, the output cache contains a different version of the requested document for each specified parameter. Multiple parameters are separated by a semicolon. Valid parameters to use are items specified on the GET query string or parameters set in the body of a POST command.

If you want to use the HttpCachePolicy class to define caching parameters, first set the expiration and the cacheability of the page using the SetExpires and SetCacheability methods. Next, set the VaryByParams property as shown here:

Response.Cache.SetExpires(DateTime.Now.AddSeconds(60));
Response.Cache.SetCacheability(HttpCacheability.Public);
Response.Cache.VaryByParams["employeeid;lastname"] = true;

This code snippet shows how to vary page output based on the employee ID and the last name properties. Note that the Cache property on the HttpResponse class is just an instance of the HttpCachePolicy type.

Most ASP.NET pages do postbacks. Let’s consider the page in Figure 18-8. The page has cache duration of, say, 30 seconds, but its actual output depends on the selection the user makes every time the page is displayed. The drop-down list (named Countries) has auto-postback functionality and places a POST request for the same page whenever you change the selection.

Figure 18-8. To properly cache pages that post back, you need to vary them by one or more parameters.

With VaryByParam set to None, you’ll wait 30 seconds (or whatever the cache duration is) to have your country selection processed. It is a bit frustrating: no matter which selection you make, it is blissfully ignored and the same page is displayed.

Two points clearly emerge from this discussion. First, pages with static content are a much better fit for caching than interactive pages. Second, the postback mechanism returns a bunch of form parameters. You need to vary the cached copies of the page by the most critical of them. Varying by the selected countries is exactly what we need. The directive shown next stores each country-specific page for 30 seconds:

<%@ OutputCache VaryByParam="Countries" Duration="30" %>

The bottom line is that enabling page output caching might not be painless for interactive pages. It is free of pain and charge for relatively static pages like those describing a product, a customer, or some news.

The VaryByHeader attribute and the HttpCachePolicy’s VaryByHeaders property allow you to cache multiple versions of a page, according to the value of one or more HTTP headers that you specify.

If you want to cache pages by multiple headers, include a semicolon-delimited list of header names. If you want to cache a different version of the page for each different header value, set the VaryByHeader attribute to an asterisk (*). For example, the following declaration caches for one-minute pages based on the language accepted by the browser. Each language will have a different cached copy of the page output.

<%@ OutputCache Duration="60" VaryByParam="None"
    VaryByHeader="Accept-Language" %>

If you opt for a programmatic approach, here’s the code to use that leverages the VaryByHeaders property of the HttpCachePolicy class:

Response.Cache.VaryByHeaders["Accept-Language"] = true;

If you want to programmatically vary the pages in the cache by all HTTP header names, use the VaryByUnspecifiedParameters method of the HttpCacheVaryByHeaders class:

HttpCacheVaryByHeaders.VaryByUnspecifiedParameters();

The preceding code is equivalent to using the asterisk with the VaryByHeader attribute.

The VaryByCustom attribute in the @OutputCache directive allows you to vary the versions of page output by the value of a custom string. The string you assign to the VaryByCustom attribute simply represents the description of the algorithm employed to vary page outputs. The string is then passed to the GetVaryByCustomString method, if any, in the global.asax file. The method takes the string and returns another string that is specific to the request. Let’s examine a concrete example—varying pages by the type of device that requests the page. You use, say, the string device with the VaryByCustom attribute:

<%@ OutputCache Duration="60" VaryByParam="None" VaryByCustom="device" %>

Next, you add your application-specific GetVaryByCustomString method in the global.asax file. Here’s a possible implementation:

public override String GetVaryByCustomString(HttpContext context, String custom)
{
    if (custom == "device")
        return context.Request.Browser.Type;
    return base.GetVaryByCustomString(context, custom);
}

The output of the page is varied by user agent string. You can use any other custom information as long as the information is available through the HttpContext class. You can’t use information that is known only when the page is loaded, such as the theme. Custom information gathered by a custom HTTP module might be used if the HTTP module parks the information in the Items collection of the HttpContext object, and as long as the HTTP module is triggered before the request to resolve the page output cache is made.

Nicely enough, the feature just described—varying pages by user agent strings—has been natively available since ASP.NET 1.0. The only difference is that it uses the keyword browser instead of device. In other words, the following code is perfectly acceptable and leverages the implementation of GetVaryByCustomString on the base HttpApplication class:

<%@ OutputCache Duration="60" VaryByParam="None" VaryByCustom="browser" %>

You use the SetVaryByCustom method on the HttpCachePolicy class if you don’t like the declarative approach:

Response.Cache.SetVaryByCustom("browser");

A user control is a Web form saved to a distinct file with an .ascx extension. The similarity between user controls and pages is not coincidental. You create a user control in much the same way you create a Web form, and a user control is made of any combination of server and client controls sewn together with server and client script code. After it is created, the user control can be inserted in an ASP.NET page like any other server control. ASP.NET pages see the user control as an atomic, encapsulated component and work with it as with any other built-in Web control.

The internal content of the user control is hidden to the host page. However, the user control can define a public programming interface and filter access to its constituent controls via properties, methods, and events.

User controls and pages have so much in common that transforming a page, or a part of it, into a user control is no big deal. You copy the portion of the page of interest to a new .ascx file and make sure the user control does not contain any of the following tags: <html>, <body>, or <form>. You complete the work by associating a code-behind file (or a <script runat=“server”> block) to code the expected behavior of the user control. Finally, you add a @Control directive in lieu of the @Page directive. Here’s an example of a user control:

<%@ Control Language="C#" CodeBehind="Message.ascx.cs" Inherits="Message" %>
<span style="color:<%= ForeColor%>"><%= Text%></span>

Here’s the related code-behind class:

public partial class Message : System.Web.UI.UserControl
{
    public String ForeColor;
    public String Text;
}

To insert a user control into an ASP.NET page, you drag it from the project onto the Web form, when in design mode. Visual Studio .NET registers the user control with the page and prepares the environment for you to start adding code.

<%@ Page Language="C#" CodeBehind="Test.aspx.cs" Inherits="TestUserCtl" %>
<%@ Register Src="Message.ascx" TagName="Message" TagPrefix="x" %>
<html><body>
    <form id="form1" runat="server">
        <x:Message ID="Message1" runat="server" />
    </form>
</body></html>

In the page code-behind class, you work the Message1 variable as you would do with any other server control:

protected void Page_Load(Object sender, EventArgs e)
{
    Message1.ForeColor = "blue";
    Message1.Text = "Hello world";
}

User controls are not only good at modularizing your user interface, they’re also great at caching portions of Web pages. User controls, therefore, fully support the @OutputCache directive, although they do so with some differences with ASP.NET pages, as outlined in Table 18-8.

A page that contains some dynamic sections cannot be cached entirely. What if the page also contains sections that are both heavy to compute and seldom updated? In this case, you move static contents to one or more user controls and use the user control’s @OutputCache directive to set up output caching.

To make a user control cacheable, you declare the @OutputCache attribute using almost the same set of attributes we discussed earlier for pages. For example, the following code snippet caches the output of the control that embeds it for one minute:

<% @OutputCache Duration="60" VaryByParam="None" %>

The Location attribute is not supported because all controls in the page share the same location. So if you need to specify the cache location, do that at the page level and it will work for all embedded controls. The same holds true for the VaryByHeader attribute.

The output of a user control can vary by custom strings and form parameters. More often, though, you’ll want to vary the output of a control by property values. In this case, use the new VaryByControl attribute.

[PartialCaching(60)]
public partial class CustomersGrid : UserControl {
   ...
}

The PartialCaching attribute allows you to specify the duration and values for the VaryByParam, VaryByControl, and VaryByCustom parameters.

The VaryByControl attribute allows you to vary the cache for each specified control property. For user controls, the property is mandatory unless the VaryByParam attribute has been specified. You can indicate both VaryByParam and VaryByControl, but at least one of them is required.

The following user control displays a grid with all the customers in a given country/region. The country/region is specified by the user control’s Country property.

<%@ Control Language="C#" CodeFile="CustomersGrid.ascx.cs"
            Inherits="CustomersGridByCtl" %>
<%@ OutputCache Duration="30" VaryByControl="Country" %>

<h3><%= DateTime.Now.ToString() %></h3>
<asp:ObjectDataSource ID="ObjectDataSource1" runat="server"
    TypeName="Core35.DAL.Customers"
    SelectMethod="LoadByCountry">
</asp:ObjectDataSource>

<asp:GridView ID="GridView1" runat="server" AutoGenerateColumns="false">
    <Columns>
        <asp:BoundField DataField="ID" HeaderText="ID" />
        <asp:BoundField DataField="CompanyName" HeaderText="Company" />
        <asp:BoundField DataField="ContactName" HeaderText="Contact" />
        <asp:BoundField DataField="Country" HeaderText="Country" />
    </Columns>
</asp:GridView>

Here is the code file of the user control:

public partial class CustomersGridByCtl : System.Web.UI.UserControl
{
    public String Country;

    protected void Page_Load(Object sender, EventArgs e)
    {
        if (!String.IsNullOrEmpty(Country))
        {
            ObjectDataSource1.SelectParameters.Add("country", Country);
            GridView1.DataSourceID = "ObjectDataSource1";
        }
    }
}

The @OutputCache directive caches a different copy of the user control output based on the different values of the Country property. Figure 18-9 shows it in action.

Figure 18-9. Two pages created at different moments use the same user control output, as you can see from the creation time of the grid.

The strings you assign to VaryByControl can be properties of the user controls as well as ID property values for contained controls. In this case, you’ll get a distinct cached copy for each distinct combination of property values on the specified control.

In Figure 18-9, you see two instances of the same page sharing the cached output of a user control. Try the following simple experiment. Make a plain copy of the page (say, page1.aspx), and give it another name (say, page2.aspx). You should have two distinct pages that generate identical output. In particular, both pages contain an instance of the same cacheable user control. Let’s say that the cache duration of the user control is 30 seconds.

As the next step of the experiment, you open both pages at different times while the cache is still valid. Let’s say you open the second page ten seconds later than the first. Interestingly enough, the two pages no longer share the same copy of user control output, as Figure 18-10 documents.

Figure 18-10. Distinct pages don’t automatically share the output of the same user control.

By default, distinct pages don’t share the output of the same cacheable user control. Each page will maintain its own copy of the user control response, instead. Implemented to guarantee total separation and avoid any sort of conflicts, this feature is far more dangerous than one might think at first. It might lead to flooding the Web server memory with copies and copies of the user control responses—one for each varying parameter or control property and one set for each page that uses the control.

To allow distinct pages to share the same output of a common user control, you need to set the Shared attribute to true in the user control’s @OutputCache directive:

<%@ OutputCache Duration="30" VaryByParam="None" Shared="true" %>

If you plan to cache user controls—that is, if you’re trying for partial caching—it’s probably because you just don’t want to, or cannot, cache the entire page. However, a good question to ask is this: What happens if user controls are cached within a cacheable page?

Both the page and the controls are cached individually, meaning that both the page’s raw response and the control’s raw responses are cached. However, if the cache duration is different, the page duration wins and user controls are refreshed only when the page is refreshed.

A cacheable user control can be embedded both in a cacheable page and in a wrapper-cacheable user control.

if (CustomerGrid1 != null)
   CustomerGrid1.Country = "USA";

The @OutputCache directive for pages supports the CacheProfile string attribute, which references an entry under the <outputCacheProfiles> section in the web.config file:

<caching>
   <outputCacheSettings>
      <outputCacheProfiles>
          <add name="..." enabled="true|false" duration="..."
               location="..." sqlDependency="..."
               varyByCustom="..." varyByControl="..."
               varyByHeader="..." varyByParam="..."
                              noStore=true|false"
          />
     </outputCacheProfiles>
  </outputCacheSettings>
</caching>

Basically, by defining a named entry in the <add> section you can store in the configuration file all the cache-related settings to be applied to the page. Instead of specifying the same set of parameters for each page over and over again, you can put them in the web.config file and reference them by name. In this way, you can also modify settings for a number of pages without touching the source files.

<%@ OutputCache CacheProfile="MySettings" %>

In the preceding code, the application has a MySettings entry in the <outputCacheProfiles> section and doesn’t need any additional attribute in the @OutputCache directive. As you can see, the attributes of the <add> node match the attributes of the @OutputCache directive.

With user controls, you can cache only certain portions of ASP.NET pages. With post-cache substitution, you can cache the whole page except specific regions. For example, using this mechanism, an AdRotator control can serve a different advertisement on each request even if the host page is cached.

To use post-cache substitution, you place a new control—the <asp:substitution> control—at the page location where content should be substituted, and you set the MethodName property of the control to a callback method. Here’s a quick example:

<form id="form1" runat="server">
    <h3>The output you see has been generated at:
        <%=DateTime.Now.ToString() %> and is valid for 30 seconds</h3>
    <hr />
     This content is updated regularly
     <h2><asp:Substitution ID="Substitution1" runat="server"
              MethodName="WriteTimeStamp" /></h2>
    <hr />
    This is more static and cached content
    <asp:Button runat="server" Text="Refresh" />
 </form>

The MethodName property must be set to the name of a static method that can be encapsulated in an HttpResponseSubstitutionCallback delegate, as follows:

public static string WriteTimeStamp(HttpContext context)
{
    return DateTime.Now.ToString();
}

Whatever string the method returns will be rendered out and becomes the output of the Substitution control. Note also that the callback method must be static and thread-safe. The HttpContext parameter to the method can be used to retrieve request parameters such as query string variables, authentication information, or personalization details.

You can also set up post-cache substitution programmatically through the WriteSubstitution method of the HttpResponse object:

Response.WriteSubstitution(
    new HttpResponseSubstitutionCallback(WriteTimeStamp));

The preceding call inserts a sort of placeholder in the response, which will be replaced with the output of the method. This trick allows the AdRotator control to automatically display a new banner even on cached pages.

The use of post-cache substitution automatically enables server caching for the page output. If the page is configured for client output caching, the setting is ignored. The reason for this change lies in the fact that markup editing is necessarily a server-side operation. In addition, a page that makes use of post-cache substitution can’t rely on IIS kernel caching because ASP.NET needs to do some work before the page can be served to the user. In light of this, the page can’t just be served by IIS without first involving ASP.NET.

For performance reasons, you should also avoid calling the Substitution control from within the callback. If you call it from there, the callback will maintain a reference to the control and the page containing the control. As a result, the page instance won’t be garbage-collected until the cached content expires.

Up until ASP.NET 4, the mechanics of output cache providers was hardcoded in a system component and wasn’t exposed to developers. Most of the internal implementation of the component was public, but still there was no way to change it—take it or leave it were the only choices.

In ASP.NET 4, the component has been abstracted to a provider model (much like the model you have for session state or membership) and became replaceable by developers. When you use the code snippets shown earlier (where you don’t explicitly specify any provider information), you end up using the default provider, which delivers the same behavior as in previous versions of ASP.NET. This means that the output of pages is kept in the ASP.NET Cache object and, subsequently, in the memory of the worker process servicing the current request.

Where else would you like to store the output of ASP.NET pages on the server side? A possibility is storing the output in some permanent store, such as disk files or databases. The benefit in this case is that you release a lot of the worker process memory while gaining the chance to store much larger amounts of data on disk.

A much more enticing scenario, however, is using a distributed cache instead of a server-bound cache to store the output of pages. AppFabric Caching Services, as well as many of the commercial solutions I mentioned earlier in the chapter, offer an ASP.NET-compatible output cache provider that you roll in your application in lieu of the default one. Here’s how you change the output cache provider. It is as simple as editing a section of the web.config file:

<caching>
   <outputCache defaultProvider="AspNetInternalProvider">
     <providers>
       <add name="FileCache"
            type="Samples.YourCacheProvider, Samples" />
     </providers>
  </outputCache>
</caching>

A custom output cache provider is a class that inherits from System.Web.Caching. OutputCacheProvider which, in turn, inherits from ProviderBase. The class consists of four abstract methods, as shown here:

public abstract Object Add(String key, Object entry, DateTime utcExpiry);
public abstract Object Get(String key);
public abstract void Remove(String key);
public abstract void Set(String key, Object entry, DateTime utcExpiry);

In ASP.NET 4, the mechanism of output caching has been made open, but no additional providers are provided as part of the framework. At the following URL, however, you can find the source code of the AppFabric Caching Services output provider written by one of the Microsoft ASP.NET architects: http://aspnet.codeplex.com/releases/view/46576.