The appSettings section of Web.config holds application-specific values (strings) that are keyed by other strings. Its purpose is to parameterize an application’s behavior, and to allow that behavior to be modified without changing any source code.

Suppose, for example, that you coded the following statements into a Page_Load handler:

SqlDataAdapter adapter = new SqlDataAdapter
    ("select * from titles where price != 0",
     "server=hawkeye;database=pubs;uid=sa;pwd=");
DataSet ds = new DataSet ();
adapter.Fill (ds);

The only problem with this code is that if the database connection string changes—if the database moves to another machine, for example, or if the user name or password changes—you have to modify the code to update the database connection string. If you work in a big company, code modifications probably trigger a mountain of paperwork and require all or part of the application to be retested and reapproved.

A better solution to encoding connection strings and other data that’s subject to change over the lifetime of an application is to put it in the appSettings section of Web.config. The following Web.config file declares a connection string and assigns it the name “MyConnectionString”:

<configuration>
  <appSettings>
    <add key="MyConnectionString"
      value="server=hawkeye;database=pubs;uid=sa;pwd=" />
  </appSettings>
</configuration>

Page_Load can be rewritten to extract the connection string from Web.config:

string conn = ConfigurationSettings.AppSettings["MyConnectionString"];
SqlDataAdapter adapter = new SqlDataAdapter
    ("select * from titles where price != 0", conn);
DataSet ds = new DataSet ();
adapter.Fill (ds);

AppSettings is a static method belonging to the ConfigurationSettings class in the FCL’s System.Configuration namespace. It retrieves values by name from the appSettings section of Web.config. The benefit to doing it this way? Storing the database connection string in Web.config enables you to change it without touching any actual program code. It’s analogous to storing program settings in the registry in a Windows application, and it comes with all the perks but none of the drawbacks.

The system.web section of Web.config holds configuration settings used by ASP.NET. Its content is categorized by subsections. Although the type and number of subsections that can appear is technically unlimited—as developers are free to define custom subsections—the ones listed in the following table are supported by default and can be used without writing custom configuration handlers.

Here’s a sample Web.config file that enables tracing. Drop it in the application root, and ASP.NET appends useful trace information (including strings written to trace output with Trace.Write and Trace.Warn) to the application’s pages:

<configuration>
  <system.web>
    <trace enabled="true" />
  </system.web>
</configuration>

Here’s another Web.config file that enables tracing, instructs ASP.NET to compile debug executables, moves session state to a back-end SQL Server database (a topic you’ll learn about later in this chapter), tells ASP.NET to assume code found in the application’s files is written in C# unless otherwise noted, and enables view state validation by appending hashes to view state values round-tripped to the client:

<configuration>
  <system.web>
    <trace enabled="true" />
    <sessionState
      mode="SQLServer"
      sqlConnectionString="server=localhost;uid=sa;pwd="
    />
    <compilation debug="true" defaultLanguage="c#" />
    <pages enableViewStateMac="true" />
  </system.web>
</configuration>

Because element and attribute names in XML are case-sensitive, statements in Web.config are case-sensitive, too. For example, the statement

<Pages enableviewstatemac="true" />

isn’t valid and will generate an error message. Even attribute values are case-sensitive. The statement

<pages enableViewStateMac="True" />

is invalid because the T in “true” must be lowercase.

If you’re going to use Web.config files to affect configuration changes, knowing what the default settings are so that you know what needs changing and what doesn’t is helpful. Default configuration settings are defined in Machine.config, which is located in the Windows (or Winnt) directory’s Microsoft.NETFrameworkvn.n.nnnnConfig directory. For example, tracing is disabled by default as the result of the following statement in Machine.config:

<trace enabled="false" ... />

Because Machine.config holds configuration settings for all managed applications on the host machine, modifying Machine.config changes the defaults machine-wide. If you want tracing to be enabled by default, simply edit the statement above to read

<trace enabled="true" ... />

Settings in Web.config, by contrast, apply only to local applications.

The Microsoft .NET SDK documents most of the elements and attributes that Web.config supports out of the box. But the ultimate source of reference is Machine.config. It’s sprinkled with comments placed there by Microsoft developers documenting the options available and the syntax of individual elements. If you have a question about Web.config and can’t find an answer in the documentation, turn to Machine.config; chances are it’ll have the answer you’re looking for.

One of the hallmarks of Web.config files is configuration inheritance. Simply put, configuration inheritance means that settings specified in a Web.config file pertain to all files in the host directory (the one that holds Web.config) and its subdirectories. In other words, if you put the following Web.config file in wwwroot:

<configuration>
  <system.web>
    <compilation defaultLanguage="c#" />
  </system.web>
</configuration>

the default language for subdirectories stemming from wwwroot is also C#. Why? Because subdirectories inherit configuration settings from parent directories.

Subdirectories inherit their parents’ configuration settings, but they can override those settings with Web.config files of their own. As an example, consider the directory structure in Figure 9-3. The top-level directory contains a Web.config file that sets the default language to C#. One of its subdirectories holds a Web.config file that sets the default language to Visual Basic .NET; the other subdirectory has no Web.config file. In this case, C# is the default language in wwwroot and wwwrootCSharpFiles, but Visual Basic .NET is the default language in wwwrootVBFiles. If the subdirectories contained subdirectories of their own, those subdirectories too would inherit settings from their parents. Specifically, subdirectories underneath wwwrootCSharpFiles would default to C# and subdirectories beneath wwwrootVBFiles would default to Visual Basic .NET. Those settings, of course, could be overridden by placing Web.config files in the subdirectory’s subdirectories.

Figure 9-3. Configuration inheritance.

Machine.config sits at the top of the inheritance hierarchy. Default settings for the .NET Framework, ASP.NET included, are defined in Machine.config and are inherited by all framework applications. That’s why settings in Machine.config apply to every managed application on the machine, and why you can look to Machine.config to determine what a server’s default settings are. When you drop a Web.config file into a local directory, all you’re really doing is overriding settings inherited from Machine.config.

Global directives, also known as application directives, provide application-wide instructions to the ASP.NET compilation engine. A Global.asax file supports three types of global directives:

Global.asax can contain just one @ Application directive, but it places no limit on the number of @ Import and @ Assembly directives.

<%@ Application Description="My First ASP.NET Application" %>

<%@ Import Namespace="System.Data" %>

<script language="C#" runat="server">
  void Application_Start ()
  {
      DataSet ds = new DataSet ();
      ds.ReadXml (Server.MapPath ("GlobalData.xml"));
      Application["GlobalData"] = ds;
  }
</script>

using System.Web;
using System.Data;

public class MyApp : HttpApplication
{
    public void Application_Start ()
    {
        DataSet ds = new DataSet ();
        ds.ReadXml ("GlobalData.xml");
        Application["GlobalData"] = ds;
    }
}

<%@ Application Inherits="MyApp" %>

<script language="C#" runat="server">
  void Application_Start ()
  {
      DataSet ds = new DataSet ();
      ds.ReadXml (Server.MapPath ("GlobalData.xml"));
      Application["GlobalData"] = ds;
  }
</script>

<%@ Import Namespace="System.Data" %>

<%@ Import Namespace="System.DirectoryServices" %>
<%@ Assembly Name="System.DirectoryServices" %>

The most common reason for including Global.asax files in ASP.NET applications is to handle global events—events that aren’t specific to a particular page but that apply to the application as a whole. Some global events are fired by the HttpApplication instances that process individual requests. Others are fired by HTTP modules—plug-in components that provide services such as authentication and output caching to ASP.NET. Some events fire on every request. Others fire at predictable junctures in an application’s lifetime, such as when the application starts or stops. Still others fire conditionally—for example, when an unhandled exception occurs. Regardless of when a global event fires or who fires it, you can process it by including a handler in Global.asax.

<script language="C#" runat="server">
  void Application_Start ()
  {
    ...
  }

  void Application_End ()
  {
    ...
  }
</script>

<script language="C#" runat="server">
  void Session_Start ()
  {
    ...
  }

  void Session_End ()
  {
    ...
  }
</script>

<script language="C#" runat="server">
  void Application_PostRequestHandlerExecute (Object sender, EventArgs e)
  {
      HttpApplication app = (HttpApplication) sender;
      app.Context.Response.Write ("<hr><center><i>" +
          "Copyright © 2002 by Me, Myself, and I</i></center>");
  }
</script>

<%@ Import Namespace="System.Diagnostics" %> 

<script language="C#" runat="server"> 
  void Application_Error (Object sender, EventArgs e)
  {
      // Formulate a message to write to the event log
      string msg = "Error accessing " + Request.Path + "
" +
          Server.GetLastError ().ToString ();

      // Write an entry to the event log
      EventLog log = new EventLog ();
      log.Source = "My ASP.NET Application";
      log.WriteEntry (msg, EventLogEntryType.Error);
  }
</script>

Global object tags create object instances declaratively. Suppose you want a new instance of ShoppingCart created for each user that visits your site. Rather than do this:

<script>
  void Session_Start ()
  {
      Session["MyShoppingCart"] = new ShoppingCart ();
  }
</script>

you can do this:

<object id="MyShoppingCart" class="ShoppingCart" scope="session"
  runat="server" />

Assuming ShoppingCart has an Add method, a Web form could add an item to a user’s shopping cart by doing this:

MyShoppingCart.Add (...);

This code might not make a lot of sense right now, but it’ll make plenty of sense by the end of the chapter.

An <object> tag’s Scope attribute assigns a scope to the object instances it creates. Scope=“Application” creates one object instance, which is shared by all users of the application. Scope=“Session” creates one object instance per session (that is, per user). Scope=“Pipeline” creates a unique instance of the object for each and every request.

ASP.NET doesn’t create objects declared with <object> tags unless it has to—that is, until they’re requested for the first time. “Lazy instantiation” prevents objects from being created unnecessarily if the application doesn’t use them.

Application state is physically represented by instances of System.Web.HttpApplicationState. Pages access instances of HttpApplicationState through the Application property that they inherit from Page; Global.asax files access them through the Application property that they inherit from HttpApplication.

HttpApplicationState properties and methods expose the contents of application state. The following statements add three stock prices keyed by stock symbols to application state and work equally in an ASPX file, in Global.asax, or in a code-behind file:

Application["AMZN"] = 10.00m;
Application["INTC"] = 20.00m;
Application["MSFT"] = 30.00m;

You can also add items to application state using HttpApplicationState.Add:

Application.Add ("AMZN", 10.00m);
Application.Add ("INTC", 20.00m);
Application.Add ("MSFT", 30.00m);

However, Add and [] behave slightly differently when adding items to application state. Add adds an item even if an item with the specified key already exists; [] does not. These statements add two separate items to application state:

Application.Add ("AMZN", 10.00m);
Application.Add ("AMZN", 11.00m);

You can retrieve both items by iterating over the contents of application state, but if you simply ask for the item keyed by “AMZN,” you’ll get back 10. The following example, by contrast, adds just one item to application state. The first statement creates the item and assigns it the value 10. The second statement changes the item’s value to 11:

Application["AMZN"] = 10.00m;
Application["AMZN"] = 11.00m;

How do you read values from application state? The following statements retrieve the stock prices inserted earlier:

decimal amzn = (decimal) Application["AMZN"];
decimal intc = (decimal) Application["INTC"];
decimal msft = (decimal) Application["MSFT"];

The casts are necessary to convert the generic System.Object references retrieved from application state to strong types. To remove items from application state, call Remove, RemoveAt, RemoveAll, or Clear through the Application property. Clear and RemoveAll are semantically equivalent; they empty application state by removing all items.

Internally, ASP.NET uses a reader/writer lock to synchronize access to application state so that two threads representing two concurrent requests can’t read it and write it at the same time. However, if you perform multistep operations on application state and need them to be treated as one atomic operation—that is, to ensure thread A can’t read from application state while thread B performs a multistep update—you should surround the updates with calls to Lock and UnLock, as shown here:

Application.Lock ();
Application["ItemsSold"] = (int) Application["ItemsSold"] + 1;
Application["ItemsLeft"] = (int) Application["ItemsLeft"] - 1;
Application.UnLock ();

In between calls to Lock and UnLock, other threads that call Lock and UnLock can neither read nor write application state. Locking and unlocking is necessary only when multiple operations performed on application state must be treated as one.

The application in Example 9-4 uses application state to keep a running count of the number of times its pages are requested. Its one and only page is AppCounter.aspx, which reads the count from application state, increments it, writes the incremented count back to application state, and displays it. The Application_Start handler in Global.asax writes the count to application state each time the application starts up. The count is persistent—that is, it doesn’t reset to 0 when the application shuts down—because Global.asax includes an Application_End handler that saves the count in a text file named Count.txt when the application ends. Next time the application starts up, Application_Start reads the count from the file. Only if the file doesn’t exist or contains invalid data does Application_Start initialize the count to 0.

Application_Start calls Server.MapPath to convert Count.txt’s URL into a physical path name. Rather than do the same, Application_End reads the path from a static field (_path) initialized by Application_Start. The reason? Server.MapPath throws an exception if called from Application_End. By the time Application_End is called, the application has almost shut down and some HttpApplication facilities normally available to handlers in Global.asax are no longer usable. Server.MapPath happens to be one of those facilities.

Take the application for a spin by copying the two source code files to wwwroot (or the virtual directory of your choice) and calling up AppCounter.aspx in your browser. The resulting page should show a count of 1. Refresh the page a few times and observe that each refresh increments the count. Now close your browser, open a command prompt window, and type iisreset to restart IIS. This command shuts down the application, which causes Application_End to be called, which writes the count to Count.txt. Call up AppCounter.aspx again and the count should pick up right where it left off.

<%@ Import NameSpace="System.IO" %>

<script language="C#" runat="server">
  static string _path;

  void Application_Start ()
  {
      StreamReader reader = null;

      try {
          // If Count.txt exists, read the count from it and
          // store the count in application state
          _path = Server.MapPath ("/Count.txt");
          reader = new StreamReader (_path);
          string line = reader.ReadLine ();
          int count = Convert.ToInt32 (line);
          Application["Count"] = count;
      }
      catch (Exception) {
          // If Count.txt does not exist or contains an invalid
          // count, store a 0 in application state
          Application["Count"] = 0;
      }
      finally {
          // Close the StreamReader
          if (reader != null)
              reader.Close ();
      }
  }

  void Application_End ()
  {
      StreamWriter writer = null;

      try {
          // Save the current count in Count.txt
          writer = new StreamWriter (_path, false);
          writer.Write (Application["Count"]);
      }
      finally {
          // Close the StreamWriter
          if (writer != null)
              writer.Close ();
      }
  }
</script

<%@ Page Language="C#" %>

<html>
  <body>
    <%
      // Fetch the count and increment it by 1. Lock application state
      // to prevent the count from changing as it’s being updated.
      Application.Lock ();
      int count = (int) Application["Count"] + 1;
      Application["Count"] = count;
      Application.UnLock ();

      // Write the count to the page
      Response.Write ("Pages in this application " +
          "have been requested " + count + " time");
      if (count > 1)
          Response.Write ("s");
      Response.Write (".");
    %>
  </body>
</html>

The application cache is represented by instances of System.Web.Caching.Cache. Like application state, the application cache is exposed to program code through properties in ASP.NET base classes. Pages access the application cache through Page.Cache; Global.asax files access it through HttpApplication.Context.Cache. The following statements add three items—once more, decimal stock prices keyed by stock symbols—to the application cache from Global.asax:

Context.Cache["AMZN"] = 10.00m;
Context.Cache["INTC"] = 20.00m;
Context.Cache["MSFT"] = 30.00m;

ASPX files add items to the application cache without using Context as an intermediary:

Cache["AMZN"] = 10.00m;
Cache["INTC"] = 20.00m;
Cache["MSFT"] = 30.00m;

Items can also be added to the application cache with Cache.Insert:

Cache.Insert ("AMZN", 10.00m);
Cache.Insert ("INTC", 20.00m);
Cache.Insert ("MSFT", 30.00m);

Both Insert and [] replace an existing item if an existing key is specified. In other words, the following statements add just one item to the cache but modify its value three times:

Cache["AMZN"] = 10.00m;
Cache["AMZN"] = 11.00m;
Cache.Insert ("AMZN", 12.00m);
Cache.Insert ("AMZN", 13.00m);

Here’s how a Web form retrieves items from the application cache:

decimal amzn = (decimal) Cache["AMZN"];
decimal intc = (decimal) Cache["INTC"];
decimal msft = (decimal) Cache["MSFT"];

As with application state, the cast is necessary to let the compiler know what kind of items were retrieved from the cache. To remove an item from the application cache, call Cache.Remove.

The application cache doesn’t have Lock and UnLock methods as application state does. But that doesn’t mean locking isn’t necessary; it means you have to come up with your own mechanism for doing it. System.Threading.ReaderWriterLock is the perfect tool for the job. Assuming rwlock is an instance of ReaderWriterLock, here’s how you’d lock the application cache during an update:

rwlock.AcquireWriterLock (Timeout.Infinite);
try {
    Cache["ItemsSold"] = (int) Cache["ItemsSold"] + 1;
    Cache["ItemsLeft"] = (int) Cache["ItemsLeft"] - 1;
}
finally {
    rwlock.ReleaseWriterLock ();
}

And here’s how you’d read “ItemsSold” and “ItemsLeft” values from the cache:

rwlock.AcquireReaderLock (Timeout.Infinite);
try {
    int sold = (int) Cache["ItemsSold"];
    int left = (int) Cache["ItemsLeft"];
}
finally {
    rwlock.ReleaseReaderLock ();
}

As with application state, locking the application cache is necessary only when performing multistep updates that are to be treated as atomic operations.

If you use the application cache as shown above—that is, if you do nothing more than add static items and later retrieve them—then the application cache is little better than application state. The real power of the cache comes into play when you assign items expiration policies and process the callbacks that fire when the items expire. The following example, which is taken from a Global.asax file, initializes the application cache with a Hashtable containing three stock prices when the application starts up. It also sets the item to expire 5 minutes after it’s added to the cache:

<script language="C#" runat="server">
  void Application_Start ()
  {
      Hashtable stocks = new Hashtable ();
      stocks.Add ("AMZN", 10.00m);
      stocks.Add ("INTC", 20.00m);
      stocks.Add ("MSFT", 30.00m);

      Context.Cache.Insert ("Stocks", stocks, null,
          DateTime.Now.AddMinutes (5), Cache.NoSlidingExpiration);
  }
</script>

Insert’s fourth parameter—a DateTime value specifying a time 5 minutes hence—tells ASP.NET to remove the item from the cache in 5 minutes. That’s called an absolute expiration. As an alternative, you can assign the item a sliding expiration by passing a TimeSpan value in the fifth parameter and Cache.NoAbsoluteExpiration in the fourth. A sliding expiration configures the item to expire when it has not been accessed (retrieved from the cache) for a specified length of time.

Absolute expirations and sliding expirations are one way to define expiration policies. Another option is to use Insert’s third parameter to establish a dependency between an item added to the cache and one or more files or directories. When the file or directory changes—when the file is modified, for example—ASP.NET removes the item from the cache. The following code sample initializes a DataSet from an XML file, adds the DataSet to the application cache, and creates a dependency between the DataSet and the XML file so that the DataSet is automatically removed from the cache if someone modifies the XML file:

DataSet ds = new DataSet ();
ds.ReadXml (Server.MapPath ("Stocks.xml"));
Context.Cache.Insert ("Stocks", ds,
    new CacheDependency (Server.MapPath ("Stocks.xml")));

Used this way, a CacheDependency object defines a dependency between a cached item and a file or directory. You can also use CacheDependency to set an item to expire when another item in the cache expires. Simply pass an array of key names identifying the item or items on which your item depends in the second parameter to CacheDependency’s constructor. If you don’t want to establish a file or directory dependency also, pass null in the constructor’s first parameter.

Cache.Insert also lets you assign priorities to items added to the application cache. When memory grows short, ASP.NET uses these priorities to determine which items to remove first. If you don’t specify otherwise, an item’s priority is CacheItemPriority.Normal. Other valid CacheItemPriority values, in order of lowest to highest priorities, are Low, BelowNormal, AboveNormal, High, and NotRemovable. Priority values are specified in Insert’s sixth parameter. The following statement inserts a DataSet named ds into the application cache, sets it to expire 1 hour after the last access, and assigns it a relatively high priority so that items with default or lower priority will be purged first in low-memory situations:

Context.Cache.Insert ("Stocks", ds, null,
    Cache.NoAbsoluteExpiration, TimeSpan.FromHours (1),
    CacheItemPriority.AboveNormal, null);

Specifying a CacheItemPriority value equal to NotRemovable is the only way to ensure that an item added to the cache will still be there when you retrieve it. That’s important, because it means code that retrieves an item from the application cache should always verify that the reference to the item returned by the cache isn’t null—unless, of course, the item was marked NotRemovable.

All items except those marked NotRemovable are subject to removal from the cache at any time if ASP.NET needs the memory for other purposes. If you’d like to be notified when an item is removed, you can pass a CacheItemRemovedCallback delegate to Insert identifying the method you want ASP.NET to call if and when it removes the item from the cache. The following example extends one of the examples in the previous section by adding a DataSet to the application cache, configuring it to expire when the XML file it’s initialized from changes, and automatically replacing the old DataSet with a new one using a callback method:

<%@ Import Namespace="System.Data" %>

<script language="C#" runat="server">
  static Cache _cache;
  static string _path;

  void Application_Start ()
  {
      _cache = Context.Cache;
      _path = Context.Server.MapPath ("Stocks.xml");

      DataSet ds = new DataSet ();
      ds.ReadXml (_path);

      _cache.Insert ("Stocks", ds, new CacheDependency (_path),
          Cache.NoAbsoluteExpiration, Cache.NoSlidingExpiration,
          CacheItemPriority.Default,
          new CacheItemRemovedCallback (RefreshDataSet));
  }

  static void RefreshDataSet (String key, Object item,
      CacheItemRemovedReason reason)
  {
      DataSet ds = new DataSet ();
      ds.ReadXml (_path);

      _cache.Insert ("Stocks", ds, new CacheDependency (_path),
          Cache.NoAbsoluteExpiration, Cache.NoSlidingExpiration,
          CacheItemPriority.Default,
          new CacheItemRemovedCallback (RefreshDataSet));
  }
</script>

When RefreshDataSet (or any other CacheItemRemovedCallback method) is called, the first parameter identifies the string that the item was keyed with, the second identifies the item itself, and the third specifies why the item was removed. This example is simple enough that no callback parameters need to be examined. In a more complex application that stores multiple items in the application cache, however, you’d probably use at least the first of the three parameters to determine which item needs refreshing.

Earlier, I showed you how to add items to the application cache using Insert and []. You can also add items with Cache.Add. Unlike Insert, however, Add isn’t overloaded to support simplified usage; when you call it, you have to provide seven different parameters, as shown here:

Context.Cache.Add ("Stocks", ds, null,
    Cache.NoAbsoluteExpiration, Cache.NoSlidingExpiration,
    CacheItemPriority.Default, null);

Add doesn’t behave exactly like Insert. Add adds an item to the cache, but only if the key you specify in Add’s first parameter doesn’t already exist. By contrast, Insert always adds an item to the cache. If the key specified in Insert’s first parameter already exists, Insert simply replaces the old item with the new one.

For an example of how the ASP.NET application cache might be used to improve performance, consider the following ASPX file:

<%@ Import Namespace="System.IO" %>

<html>
  <body>
    <asp:Label ID="Output" RunAt="server" />
  </body>
</html>

<script language="C#" runat="server">
  void Page_Load (Object sender, EventArgs e)
  {
      ArrayList quotes = new ArrayList ();
      StreamReader reader = new StreamReader (Server.MapPath ("Quotes.txt"));

      for (string line = reader.ReadLine (); line != null;
          line = reader.ReadLine ())
          quotes.Add (line);

      reader.Close ();

      Random rand = new Random ();
      int index = rand.Next (0, quotes.Count - 1);
      Output.Text = (string) quotes[index];
  }
</script>

Each time this ASPX file is requested, it opens a text file named Quotes.txt, reads its contents, and displays a randomly selected line. If Quotes.txt contains a collection of famous quotations, a randomly selected quotation appears each time the page is refreshed.

So what’s wrong with this picture? Nothing—unless, that is, you value performance. Each time the page is requested, it opens and reads the text file. Consequently, each and every request results in a physical file access. File accesses impede performance because file I/O is a relatively time-consuming undertaking.

This ASPX file, simple as it is, can benefit greatly from the ASP.NET application cache. Suppose that instead of reading Quotes.txt every time the page is requested, you read it once—when the application starts up—and store it in the application cache. Rather than physically access the file, the ASPX file could then retrieve a line directly from the application cache. Furthermore, the cached data could be configured so that it’s deleted from the cache if the file that it comes from changes. You could write a callback method that refreshes the cache when the data is removed. That way, the application would incur just one physical file access at startup and would never access the file again unless the contents of the file change.

Figure 9-5 shows what the output looks like for a Web application that fits the description in the previous paragraph. Example 9-6 contains the source code. Global.asax’s Application_Start method reads the contents of Quotes.txt into an ArrayList and inserts the ArrayList into the application cache. It also establishes a dependency between the ArrayList and Quotes.txt so that if the latter changes, the ArrayList is removed from the cache and Global.asax’s RefreshQuotes method is called. RefreshQuotes refreshes the cache by rereading the file and placing the resulting ArrayList in the cache. The ASPX file—SmartQuotes.aspx—retrieves the ArrayList and displays a randomly selected line. And just in case it hits the cache after the ArrayList is deleted and before the new one is added, SmartQuotes.aspx displays a “Server busy” message if the cache read returns a null reference. Refreshing the page again should replace “Server busy” with a famous quotation. To try the application for yourself, copy the source code files to wwwroot or the virtual directory of your choice, open SmartQuotes.aspx in your browser, and refresh the page a few times.

Figure 9-5. The SmartQuotes Web page in action.

<%@ Import NameSpace="System.IO" %>

<script language="C#" runat="server">

  static Cache _cache = null;
  static string _path = null;

  void Application_Start ()
  {
      _cache = Context.Cache;
      _path = Server.MapPath ("Quotes.txt");

      ArrayList quotes = ReadQuotes ();

      if (quotes != null) {
          _cache.Insert ("Quotes", quotes, new CacheDependency (_path),
              Cache.NoAbsoluteExpiration, Cache.NoSlidingExpiration,
              CacheItemPriority.Default,
              new CacheItemRemovedCallback (RefreshQuotes));
      }
  }

  static void RefreshQuotes (String key, Object item,
      CacheItemRemovedReason reason)
  {
      ArrayList quotes = ReadQuotes ();

      if (quotes != null) {
          _cache.Insert ("Quotes", quotes, new CacheDependency (_path),
              Cache.NoAbsoluteExpiration, Cache.NoSlidingExpiration,
              CacheItemPriority.Default,
              new CacheItemRemovedCallback (RefreshQuotes));
      }
  }

  static ArrayList ReadQuotes ()
  {
      ArrayList quotes = new ArrayList ();
      StreamReader reader = null;

      try {
          reader = new StreamReader (_path);
          for (string line = reader.ReadLine (); line != null;
              line = reader.ReadLine ())
              quotes.Add (line);
      }
      catch (IOException) {
          return null;
      }
      finally {
          if (reader != null)
              reader.Close ();
      }
      return quotes;
  }
</script>

<%@ Import Namespace="System.IO" %>

<html>
  <body>
    <asp:Label ID="Output" RunAt="server" />
  </body>
</html>

<script language="C#" runat="server">
  void Page_Load (Object sender, EventArgs e)
  {
      ArrayList quotes = (ArrayList) Cache["Quotes"];

      if (quotes != null) {
          Random rand = new Random ();
          int index = rand.Next (0, quotes.Count - 1);
          Output.Text = (string) quotes[index];
      }
      else {
          Output.Text = "Server busy";
      }
  }
</script>

<h3>Give me chastity and continence, but not yet.</h3>
<i>Saint Augustine</i>
<h3>The use of COBOL cripples the mind; its teaching should 
  therefore be regarded as a criminal offense.</h3><i>Edsger 
  Dijkstra</i>
<h3>C makes it easy to shoot yourself in the foot; C++ makes it 
  harder, but when you do, it blows away your whole leg.</h3>
  <i>Bjarne Stroustrup</i>
<h3>A programmer is a device for turning coffee into code.</h3>
  <i>Jeff Prosise (with an assist from Paul Erdos)</i>
<h3>I have not failed. I’ve just found 10,000 ways that won’t 
  work.</h3><i>Thomas Edison</i>
<h3>Blessed is the man who, having nothing to say, abstains from 
  giving wordy evidence of the fact.</h3><i>George Eliot</i>
<h3>I think there is a world market for maybe five computers.</h3>
  <i>Thomas Watson</i>
<h3>Computers in the future may weigh no more than 1.5 tons.</h3>
  <i>Popular Mechanics</i>
<h3>I have traveled the length and breadth of this country and talked 
  with the best people, and I can assure you that data processing is a 
  fad that won’t last out the year.</h3><i>Prentice-Hall business books
  editor</i>
<h3>640K ought to be enough for anybody.</h3><i>Bill Gates</i>

Using ASP.NET session state is simplicity itself. Pages access it through the Session property that they inherit from System.Web.UI.Page. Global.asax files access it through the Session property inherited from System.Web.HttpApplication. In both cases, the Session property maps to an instance of System.Web.SessionState.HttpSessionState specially created by ASP.NET to store data for the user who originated the request.

HttpSessionState.Add adds an item to session state. As are items stored in application state or the application cache, an “item” is an instance of any managed type keyed by a string. The following statement adds an item named “10012552” to session state and assigns it the value “Quantity=1”:

Session.Add ("10012552", "Quantity=1");

Or, if you’d prefer, you can add it this way:

Session["10012552"] = "Quantity=1";

The Add method and [] operator are semantically equivalent. In other words, both add items to session state, and both replace an existing item if an existing key is specified.

Retrieving an item from session state is equally painless:

string value = Session["10012552"];

The same can be said about enumerating items and the strings that they’re keyed with:

NameObjectCollectionBase.KeysCollection keys = Session.Keys;
foreach (string key in keys) {
    // key is the item’s key
    // Session[key] returns the item’s value
       .
       .
       .
}

To remove items from session state, use HttpSessionState’s Remove, RemoveAt, and RemoveAll methods. You can also use Clear, which is equivalent to RemoveAll.

ASP.NET uses randomly generated session IDs, which aren’t unlike COM GUIDs (globally unique identifiers), to identify sessions. If you’d like to know what the ID of a given session is, you can retrieve it from the SessionID property of the corresponding HttpSessionState object. Another interesting HttpSessionState property is IsNewSession, which reveals whether the session ID was generated for the current request (true) or a previous request (false).

Incidentally, if you perform a multistep update on session state and are concerned that a read from another thread at just the wrong time might catch the data in an indeterminate state, don’t fret. ASP.NET locks session state when an HttpApplication instance fires an AcquireRequestState event and unlocks it following the next ReleaseRequestState event. The practical effect is that it’s impossible for two requests to read and write session state at the same time, even in the unlikely event that two requests that correspond to the same session overlap each other.

For a firsthand look at session state in action, check out the Web page in Example 9-7. Called SessionSpy.aspx, it uses session state to store a count of the number of times a user visits the site. The first time you request the page, you’ll be greeted as a first-time visitor and shown the ID of the session that was created for you. Each time thereafter, you’ll be told how many times you’ve visited the site (that is, requested the page).

The count is a simple integer stored in session state and keyed with the string “Count”. SessionSpy.aspx reads the HttpSessionState object’s IsNewSession property to determine whether this access is the first one to the page and its SessionID property to get the session ID.

<%@ Page Language="C#" %>

<html>
  <body>
    <%
      if (Session.IsNewSession || Session["Count"] == null) {
          Session["Count"] = 1;
          Response.Write ("Welcome! Because this is your first " +
              "visit to this site, a new session has been created " +
              "for you. Your session ID is " + Session.SessionID +
              ".");
      }
      else {
          Session["Count"] = (int) Session["Count"] + 1;
          Response.Write ("You have visited this site " +
              Session["Count"] + " times. Your session ID is still " +
              Session.SessionID + ".");
      }
    %>
  </body>
</html>

After you’ve played with the page for a few moments, start a second instance of your browser and open SessionSpy.aspx. Because the new browser instance represents a new “session” and doesn’t share cookies with the first, you’re greeted as a first-time user. But use your browser’s New Window command (Ctrl+N in most browsers) to start a third instance, and you’ll be greeted as a returning user. Why? A browser started with the New Window command doesn’t represent a new session. It shares cookies and other resources with the first instance and thus shares its session state on the server, too.

By default, ASP.NET, like ASP, uses cookies to correlate returning users to sessions on the server. Unlike ASP, ASP.NET supports cookieless session state as well. Cookieless sessions are enabled by adding cookieless=“true” to the sessionState element in Web.config or Machine.config:

<sessionState cookieless="true" />

How does ASP.NET correlate users and sessions when cookies are disabled? By using URL munging. Check out the screen in Figure 9-8, which was taken after a client retrieved a page from an ASP.NET application running in cookieless mode. The strange-looking value in parentheses in the browser’s address bar is the session ID. Before returning the page to the client, ASP.NET inserts the session ID into the URL. When the page posts back to the server, ASP.NET strips the session ID from the URL and uses it to associate the request with a session. URL munging isn’t perfect because there’s nothing preventing the user from editing the URL and invalidating the session ID. But it’s better than nothing, and it prevents ASP.NET session state from being unusable with browsers that don’t honor cookies.

You’re probably wondering, “Is there a way I can ask ASP.NET whether cookies are enabled in a browser, and if so, can I enable cookieless operation on the fly if I detect that a request came from a browser that doesn’t support cookies?” The short answer is no and no. ASP.NET doesn’t attempt to determine whether a browser supports cookies, so if you want to know, you have to find out yourself. The usual technique is to return a cookie to a browser and use Response.Redirect to redirect to a page that checks for the cookie. If the cookie’s not there, you know the browser ignored it. Another approach is to return a cookie along with some client-side script that checks for it. Even if you determine at run time that cookies aren’t supported, however, there’s not much you can do about it as far as session state is concerned because cookieless operation can’t be enabled and disabled programmatically. If you want to know whether cookieless session state is in effect, however, you can read the IsCookieless property of any HttpSessionState object.

Bottom line? If you want session state to work with as many browsers as possible, configure your application to use cookieless session state up front. If you don’t like URL munging and don’t care that your application might not work properly with browsers that have cookies disabled (many applications test for cookie support and display a warning indicating that they might not work properly if cookies are disabled), then stick with the default: cookieless=“false.”

Figure 9-8. URL containing a session ID.

Cookieless sessions are an important enhancement to ASP.NET, but even more important are ASP.NET’s new session state process models. ASP session state is always stored in memory, which makes it incompatible with Web farms (a session—and session ID—created on server A are undefined on server B). It also means that you lose everything in session state if the Web server goes down. That’s a big deal to a site like Amazon.com, which at any given time might have millions of dollars worth of potential sales sitting in virtual shopping carts. Web farms are a big deal, too, because setting up clusters of Web servers is a classic and relatively inexpensive way to scale an application to meet the demands of a growing customer base.

That’s why ASP.NET doesn’t limit session to memory on the Web server as ASP does. ASP.NET supports three session state process models:

The default is in-proc, which is very ASP-like, but simple configuration changes applied via Web.config or Machine.config switch to the state server or SQL Server model and get session state out of the ASP.NET worker process Aspnet_wp.exe and into the location of your choosing. The sections that follow describe the necessary configuration changes and also shed light on the pros and cons of the individual process models.

<sessionState ... mode="InProc" />

<sessionState mode="InProc" />

State Server Session State

The state server session state model is new in ASP.NET. It moves session state out of Aspnet_wp.exe and into a dedicated “state server” process managed by the system. The state server is actually a running instance of a service named Aspnet_state.exe. If you want to use the state server model, you must do the following:

• Start Aspnet_state.exe. You can start it manually (from the command line) by executing the following command:

  net start aspnet_state

  Or you can configure it to start automatically each time the system is started by using Windows’ Services control panel applet (Figure 9-9).

• Add a mode=“StateServer” attribute and a stateConnectionString attribute to the sessionState element in Machine.config or a local Web.config file. The latter of these two attributes identifies the machine that hosts the state server process.

  

  Figure 9-9. The ASP.NET State service.

Here’s a Web.config file that configures an application to store session state in a state server process on the same Web server that hosts the application:

<configuration>
  <system.web>
    <sessionState
      mode="StateServer"
      stateConnectionString="tcpip=localhost:42424"
    />
  </system.web>
</configuration>

And here’s one that places session state in a state server process on another machine identified by IP address:

<configuration>
  <system.web>
    <sessionState
      mode="StateServer"
      stateConnectionString="tcpip=192.168.1.2:42424"
    />
  </system.web>
</configuration>

By default, ASP.NET uses port 42424 to communicate with the state server process. That’s why “42424” appears in the state connection string. In the unlikely event that 42424 conflicts with another application on your Web server, you can change the port number by doing the following:

• Add the desired port number to the registry at HKEY_LOCAL_ MACHINESystemCurrentControlSetServicesaspnet_state ParametersPort.

• Replace 42424 with the new port number in stateConnectionString.

As an example, here’s a Web.config file that changes the session state mode to “StateServer” and directs ASP.NET to use port 31313 to connect Aspnet_wp.exe to Aspnet_state.exe:

<configuration>
  <system.web>
    <sessionState
      mode="StateServer"
      stateConnectionString="tcpip=192.168.1.2:31313"
    />
  </system.web>
</configuration>

The state server model is slower than in-proc session state because data read from and written to session state must travel across process or machine boundaries. However, the state server model prevents session state from being lost if IIS is restarted, and should the state server process be on another machine, it even allows session state to survive if the entire Web server is rebooted. Switching to the state server model is also one way to build ASP.NET applications that work with Web farms.

Figure 9-10 illustrates how the state server model solves the Web farm compatibility problem. In this example, the Web farm contains three servers. The application runs in worker processes on all three servers, but each server is configured to store session state in a state server process on a fourth machine. It’s perfectly acceptable now for data to be written to session state on server A and read back on server B because both servers refer to machine D for their session state. If you don’t want to dedicate a machine to host the state server process, no problem: simply designate one of the Web servers as the state server and point the other servers to it with stateConnectionString.

Figure 9-10. Web farm with session state in a remote state server process.

SQL Server Session State

The SQL Server process model offers the ultimate in scalability and reliability. Like the state server model, it moves session state out of Aspnet_wp.exe. But rather than store session state in an external process, the SQL Server model stores it in a Microsoft SQL Server database. You gain Web farm compatibility because you can point all your servers to a common back-end machine (the one that hosts the database). You also achieve robustness because session state is preserved no matter what—even if IIS is restarted or the Web server is reboot­ed. If SQL Server is clustered or otherwise configured to survive hard failures, you can reboot the database server itself and still preserve the contents of session state.

Configuring ASP.NET to use the SQL Server process model is a breeze. Here are the steps required:

• Create the database that holds the session state. The .NET Framework SDK provides a script that creates the database for you; it’s called InstallSqlState.sql. To run it, open a command prompt window and type the following command:

  osql -S localhost -U sa -P -i installsqlstate.sql

  This command creates a SQL Server database named ASPState on the host machine and adds to it all the tables, stored procedures, and other infrastructure that ASP.NET uses to access the database, as shown in Figure 9-11.

• Add a mode=“SQLServer” attribute and a sqlConnectionString attribute to the sessionState element in Machine.config or a local Web.config file. The latter of these two attributes provides the information ASP.NET needs to connect to the database.

  

  Figure 9-11. The ASPState database.

The following Web.config file configures an ASP.NET application to store session state in a SQL Server database on the Web server:

<configuration>
  <system.web>
    <sessionState
      mode="SQLServer"
      sqlConnectionString="server=localhost;uid=sa;pwd="
    />
  </system.web>
</configuration>

The next one does the same, but it points ASP.NET to a SQL Server database on a remote machine named “Hawkeye”:

<configuration>
  <system.web>
    <sessionState
      mode="SQLServer"
      sqlConnectionString="server=hawkeye;uid=sa;pwd="
    />
  </system.web>
</configuration>

Performance-wise, the SQL Server model is the slowest of them all, but in return for speed it virtually guarantees that session state won’t be lost. Figure 9-12 shows how the SQL Server option factors into Web farms. A dedicated server holds the state database, and all the Web servers point ASP.NET to that database. If you intend to use ASP.NET to build large, industrial-strength e-commerce sites, this is the architecture you want.

Figure 9-12. Web farm with session state in a remote SQL Server database.

public class ShoppingCart
{
  ...
}

ShoppingCart cart = new ShoppingCart ();
Session["MyShoppingCart"] = cart;

[Serializable]
public class ShoppingCart
{
  ...
}

<sessionState ... timeout="20" />

<sessionState timeout="60" />

Session.Timeout = 60;

Session.Abandon ();

Session state can also be disabled altogether. Session state exacts a modest price in both memory and performance, so if you don’t use it, you should disable it. You can disable session state for an individual page (ASPX file) with the following @ Page directive:

<%@ Page EnableSessionState="false" %>

You can disable it for an entire application by including this statement in Web.config:

<sessionState mode="Off" />

Or you can disable it for all applications by adding a mode=“Off” attribute to the sessionState element in Machine.config.

Moving session state to a remote machine and pointing all your Web servers to that machine is essential to building Web applications that are compatible with server farms. But there’s something else you have to do to deploy an ASP.NET application on a Web farm. First, a bit of background.

Each server’s Machine.config file contains a machineKey element that assigns values to a pair of cryptographic keys:

<machineKey ... validationKey="AutoGenerate" decryptionKey="AutoGenerate" />

When configured to prevent tampering by appending hashes to view state values and forms authentication cookies (a topic I’ll cover in Chapter 10), ASP.NET uses validationKey to generate the hashes. If the protection level is sufficiently high, ASP.NET goes even further and uses decryptionKey to encrypt view state and authentication cookies. “AutoGenerate” tells ASP.NET to generate a random key and store it in the host machine’s Local Security Authority (LSA). Randomly generated keys are fine for single-server installations, but in a Web farm, each server must use identical keys; otherwise, a value encrypted on one machine can’t be unencrypted on another.

Before deploying an ASP.NET application on a Web farm, you should make the following configuration change on every server in the Web farm. The change can be made in Machine.config or in a local Web.config file:

Here’s a sample Web.config file that, if used on every server on which your application is installed, configures each server to use identical validation and encryption keys:

<configuration>
  <system.web>
    <machineKey
      validationKey="DD2B3BB0B07F4FE6917B60DAFEB0D01532C1C3BB07F533A1"
      decryptionKey="C89EFEF650CA4D9C9BC986061211329A9717DC2260BC6199"
    />
  </system.web>
</configuration>

Values for validationKey and decryptionKey should by cryptographically strong to make values encrypted with them difficult to break. Various tools are available for producing cryptographically strong keys. You can even write your own key generator using the FCL’s System.Security.Cryptography.RNGCryptoServiceProvider class. (RNG stands for Random Number Generator.) However you derive your keys, be sure to apply them in a CONFIG file or your Web farm–compatible application might not be so Web farm–compatible after all.

Congo.com’s source code, shown in Example 9-14, is remarkably compact considering the amount of functionality it provides. If you don’t believe me, try coding the application as an ISAPI DLL. You’ll see what I mean.

The action begins in Global.asax. Each time a new user requests a page from the site, ASP.NET creates a session for that user and calls Global.asax’s Session_Start handler. Session_Start creates a new ShoppingCart object to serve as a container for the user’s selections and stores a reference to it in session state, keying it with the name “MyShoppingCart”:

Session["MyShoppingCart"] = new ShoppingCart ();

When the user calls up Congo.aspx and clicks an Add to Cart button, Congo.aspx’s OnItemCommand method is called on the server. OnItemCommand retrieves the product ID, title, and price of the corresponding book from the DataGrid and encapsulates them in a BookOrder object:

BookOrder order = new BookOrder (e.Item.Cells[0].Text,
    e.Item.Cells[1].Text, Convert.ToDecimal
    (e.Item.Cells[2].Text.Substring (1)), 1);

OnItemCommand then retrieves the reference to the user’s ShoppingCart from session state and adds the BookOrder to the ShoppingCart:

ShoppingCart cart = (ShoppingCart) Session["MyShoppingCart"];
if (cart != null)
    cart.AddOrder (order);

Congo.aspx’s Page_Load handler populates the DataGrid by binding it to a DataSet holding the results of a database query.

When the user clicks the View Cart button at the top of the page, Congo.com redirects the user to ViewCart.aspx with Response.Redirect:

Response.Redirect ("ViewCart.aspx");

ViewCart.aspx declares a DataGrid that’s similar to the one declared in Congo.aspx. But ViewCart.aspx’s DataGrid control doesn’t bind to a DataSet encapsulating the results of a database query; it binds to the ShoppingCart object in session state. Here’s the code that does the binding:

ShoppingCart cart = (ShoppingCart) Session["MyShoppingCart"];
  .
  .
  .
MyDataGrid.DataSource = cart.Orders;
MyDataGrid.DataBind ();

Clearly, ShoppingCart plays a huge role in Congo.com’s operation. Not only does it keep a record of the items the user selected, but it implements an Orders property that supports data binding. Where does ShoppingCart come from, and what’s the magic that enables it to work with data-binding controls?

ShoppingCart is a custom data type defined in Congo.cs. It’s accompanied by BookOrder, which is also defined in Congo.cs. The ShoppingCart class is basically a wrapper around a Hashtable. It implements a private field named _Orders that holds a Hashtable reference, and public methods that enable BookOrder objects to be added to the Hashtable and removed. It also implements a public property named Orders that exposes the Hashtable’s ICollection interface:

public ICollection Orders 
{
    get { return _Orders.Values; }
}

That’s why a DataGrid can bind to a ShoppingCart: because its Orders property exposes the underlying Hashtable’s ICollection interface. The statement

MyDataGrid.DataSource = cart.Orders;

does nothing more than put the Hashtable’s ICollection interface into the hands of the DataGrid.

Both ShoppingCart and BookOrder are tagged with Serializable attributes. That’s so they can be stored in session state regardless of the session state process model selected. As I said earlier, it’s wise to mark types that you intend to store in session state as serializable so that your source code doesn’t have to change if the process model changes.

What role does Web.config play in Congo.com’s operation? It stores the connection string that Congo.aspx uses to connect to the Pubs database. Storing the connection string in Web.config rather than hardcoding it into Congo.aspx enables it to be changed without modifying any C# code.

<configuration>
  <appSettings>
    <add key="connectString"
      value="server=localhost;database=pubs;uid=sa;pwd=" />
  </appSettings>
</configuration>

<script language="C#" runat="server">
  void Session_Start ()
  {
      Session["MyShoppingCart"] = new ShoppingCart ();
  }
</script>

<%@ Import Namespace="System.Data" %>
<%@ Import Namespace="System.Data.SqlClient" %>

<html>
  <body>
    <h1>Congo.com</h1>
    <form runat="server">
      <table width="100%" bgcolor="teal">
        <tr>
          <td>
            <asp:Button Text="View Cart" OnClick="OnViewCart"
              RunAt="server" />
          </td>
        </tr>
      </table>
      <br>
      <center>
        <asp:DataGrid ID="MyDataGrid"
          AutoGenerateColumns="false" CellPadding="2"
          BorderWidth="1" BorderColor="lightgray"
          Font-Name="Verdana" Font-Size="8pt"
          GridLines="vertical" Width="90%"
          OnItemCommand="OnItemCommand" RunAt="server">
          <Columns>
            <asp:BoundColumn HeaderText="Item ID"
              DataField="title_id" />
            <asp:BoundColumn HeaderText="Title"
              DataField="title" />
            <asp:BoundColumn HeaderText="Price"
              DataField="price" DataFormatString="{0:c}"
              HeaderStyle-HorizontalAlign="center"
              ItemStyle-HorizontalAlign="right" />
            <asp:ButtonColumn HeaderText="Action" Text="Add to Cart"
              HeaderStyle-HorizontalAlign="center"
              ItemStyle-HorizontalAlign="center"
              CommandName="AddToCart" />
          </Columns>
          <HeaderStyle BackColor="teal" ForeColor="white"
            Font-Bold="true" />
          <ItemStyle BackColor="white" ForeColor="darkblue" />
          <AlternatingItemStyle BackColor="beige"
            ForeColor="darkblue" />
        </asp:DataGrid>
    </center>
    </form>
  </body>
</html>

<script language="C#" runat="server">
  void Page_Load (Object sender, EventArgs e)
  {
      if (!IsPostBack) {
          string ConnectString =
              ConfigurationSettings.AppSettings["connectString"];
          SqlDataAdapter adapter = new SqlDataAdapter
              ("select * from titles where price != 0", ConnectString);
          DataSet ds = new DataSet ();
          adapter.Fill (ds);
          MyDataGrid.DataSource = ds;
          MyDataGrid.DataBind ();
      }
  }

  void OnItemCommand (Object sender, DataGridCommandEventArgs e)
  {
      if (e.CommandName == "AddToCart") {
          BookOrder order = new BookOrder (e.Item.Cells[0].Text,
              e.Item.Cells[1].Text, Convert.ToDecimal
              (e.Item.Cells[2].Text.Substring (1)), 1);
          ShoppingCart cart = (ShoppingCart) Session["MyShoppingCart"];
          if (cart != null)
              cart.AddOrder (order);
      }
  }

  void OnViewCart (Object sender, EventArgs e)
  {
      Response.Redirect ("ViewCart.aspx");
  }
</script>

<html>
  <body>
    <h1>Shopping Cart</h1>
    <form runat="server">
      <table width="100%" bgcolor="teal">
        <tr>
          <td>
            <asp:Button Text="Return to Shopping" OnClick="OnShop"
              RunAt="server" />
          </td>
        </tr>
      </table>
      <br>
      <center>
        <asp:DataGrid ID="MyDataGrid"
          AutoGenerateColumns="false" CellPadding="2"
          BorderWidth="1" BorderColor="lightgray"
          Font-Name="Verdana" Font-Size="8pt"
          GridLines="vertical" Width="90%"
          OnItemCommand="OnItemCommand" RunAt="server">
          <Columns>
            <asp:BoundColumn HeaderText="Item ID"
              DataField="ItemID" />
            <asp:BoundColumn HeaderText="Title"
              DataField="Title" />
            <asp:BoundColumn HeaderText="Price"
              DataField="Price" DataFormatString="{0:c}"
              HeaderStyle-HorizontalAlign="center"
              ItemStyle-HorizontalAlign="right" />
            <asp:BoundColumn HeaderText="Quantity"
              DataField="Quantity" 
              HeaderStyle-HorizontalAlign="center"
              ItemStyle-HorizontalAlign="center" />
            <asp:ButtonColumn HeaderText="Action" Text="Remove"
              HeaderStyle-HorizontalAlign="center"
              ItemStyle-HorizontalAlign="center"
              CommandName="RemoveFromCart" />
          </Columns>
          <HeaderStyle BackColor="teal" ForeColor="white"
            Font-Bold="true" />
          <ItemStyle BackColor="white" ForeColor="darkblue" />
          <AlternatingItemStyle BackColor="beige"
            ForeColor="darkblue" />
        </asp:DataGrid>
      </center>
      <h3><asp:Label ID= "Total" RunAt="server" /></h3>
    </form>
  </body>
</html>

<script language="C#" runat="server">
  void Page_Load (Object sender, EventArgs e)
  {
      ShoppingCart cart = (ShoppingCart) Session["MyShoppingCart"];
      if (cart != null) {
          MyDataGrid.DataSource = cart.Orders;
          MyDataGrid.DataBind ();
          Total.Text = String.Format ("Total Cost: {0:c}",
              cart.TotalCost);
      }
  }

  void OnItemCommand (Object sender, DataGridCommandEventArgs e)
  {
      if (e.CommandName == "RemoveFromCart") {
          ShoppingCart cart = (ShoppingCart) Session["MyShoppingCart"];
          if (cart != null) {
              cart.RemoveOrder (e.Item.Cells[0].Text);
              MyDataGrid.DataBind ();
              Total.Text = String.Format ("Total Cost: {0:c}",
                  cart.TotalCost);
          }
      }
  }

  public void OnShop (Object sender, EventArgs e)
  {
      Response.Redirect ("Congo.aspx");
  }
</script>

using System;
using System.Collections;

[Serializable]
public class BookOrder
{
    string _ItemID;
    string _Title;
    decimal _Price;
    int _Quantity;

    public string ItemID 
    {
        get { return _ItemID; }
        set { _ItemID = value; }
    }

    public string Title 
    {
        get { return _Title; }
        set { _Title = value; }
    }

    public decimal Price
    {
        get { return _Price; }
        set { _Price = value; }
    }

    public int Quantity 
    {
        get { return _Quantity; }
        set { _Quantity = value; }
    }

    public BookOrder (string ItemID, string Title, decimal Price,
        int Quantity)
    {
        _ItemID = ItemID;
        _Title = Title;
        _Price = Price;
        _Quantity = Quantity;
    }
}

[Serializable]
public class ShoppingCart
{
    Hashtable _Orders = new Hashtable ();

    public ICollection Orders 
    {
        get { return _Orders.Values; }
    }
	
    public decimal TotalCost
    {
        get 
        {
            decimal total = 0;
            foreach (DictionaryEntry entry in _Orders) {
                BookOrder order = (BookOrder) entry.Value;
                total += (order.Price * order.Quantity);
            }
            return total;
        }
    }

    public void AddOrder (BookOrder Order)
    {
        BookOrder order = (BookOrder) _Orders[Order.ItemID];
        if (order != null)
            order.Quantity += Order.Quantity;
        else
            _Orders.Add (Order.ItemID, Order);
    }

    public void RemoveOrder (string ItemID)
    {
        if (_Orders[ItemID] != null)
            _Orders.Remove (ItemID);
    }
}

Congo.com uses the default session time-out, which normally equals 20 minutes. To experience the impact of shortened time-out intervals firsthand, add the following statement to Web.config:

<sessionState timeout="1" />

Call up Congo.aspx, click a few Add to Cart buttons, verify that the items were added to the shopping cart, and return to Congo.aspx. Now wait a couple of minutes and check the shopping cart again. Because the session time-out is a mere 1 minute, the cart should be empty. Finish up by deleting the sessionState element from Web.config in order to reset the time-out interval to 20 minutes.

Because it lacks a Web.config file specifying otherwise, Congo.com settles for the default session state process model. To demonstrate the effect of moving session state out of Aspnet_wp.exe, try this simple experiment:

The answer should be zero because restarting IIS restarts ASP.NET, and restarting ASP.NET shuts down Aspnet_wp.exe. Since that’s where session is stored in the in-proc model, restarting IIS destroys all active session state, too. Now do the following:

This time, the shopping cart’s contents should still be there because session state is no longer stored in Aspnet_wp.exe. It’s in Aspnet_state.exe, which isn’t restarted when ASP.NET is restarted. If you go the extra mile and move the state server process to another machine (or use a SQL Server database on another machine to store session state), you can reboot your entire server without losing session state.

As a final learning exercise, try modifying Congo.aspx to store the DataSet that it binds to the DataGrid in the application cache. As it stands now, a physical database access is performed every time Congo.aspx is requested. Assuming the contents of the database don’t change very often, it would be far more efficient to query the database periodically, store the results in the application cache, and populate the DataGrid from the cache. Here’s a blueprint for making the change:

Once these changes are made, a physical database access will occur only every 5 minutes, no matter how often the page is requested. The performance difference will be negligible if you have only a few users, but as the load on the server increases, the improvement will be more and more noticeable. Caching frequently used data in memory is a tried-and-true means of increasing performance, and ASP.NET’s application cache is the perfect tool for the job.