Chapter 14: Application Data Caching

Chapter 14

Application Data Caching

After completing this chapter, you will be able to

• Improve the performance of your application by using the application cache

• Avoid unnecessary round-trips to the database

• Manage items in the cache

This chapter covers ASP.NET's built-in data caching features. Caching is a long-standing means of improving the performance of any software system. The idea is to place frequently used data in quickly accessed media. Even though access times for mass storage continue to improve, accessing data from a standard hard disk is much slower than accessing it in memory. By taking often-used data and making it available quickly, you can improve the performance of your application dramatically.

The ASP.NET runtime includes a dictionary (key-value map) of CLR objects. The map (named Cache) lives with the application and is available via the HttpContext and System.Web.UI.Page. Using the cache is very much like using the Session object. You may access items in the cache using an indexer. In addition, you may control the lifetime of objects in the cache and even set up links between the cached objects and their physical data sources. Let's start by examining a case in which using the cache is justified.

Making an Application that Benefits from Caching

1. Create a new site. Call it UseDataCaching.

2. Borrow the UseDataList code from the example in Chapter 13. To bring it into your new project, right-click on the project in solution explorer. Choose Add Existing Item. Navigate the to the UseDataList.aspx and UseDataList.aspx.cs code from Chapter 13.

   The code you imported refers to the database in the SessionState example. That's okay. If you want to, you can change it to the database in this application's App_Data directory, but it's not strictly necessary as long as the path points to an available database somewhere on your system.

3. Examine the GetInventory, the BindToInventory, and the Page_Load methods. Listing 14-1 shows the code.

   Listing 14-1

      protected DataTable GetInventory()    {    String strConnection =       @"Provider=Microsoft.Jet.OLEDB.4.0;       DataSource=       c:\\inetpub\\wwwroot\\SessionState\\App_Data\\ASPDotNetStepByStep.mdb";         DbProviderFactory f =          DbProviderFactories.GetFactory("System.Data.OleDb");       DbConnection connection = f.CreateConnection();       connection.ConnectionString = strConnection;         connection.Open();       DbCommand command = f.CreateCommand();       command.CommandText = "Select * from DotNetReferences";       command.Connection = connection;         IDataReader reader = command.ExecuteReader();         DataTable dt = new DataTable();       dt.Load(reader);       reader.Close();       connection.Close();       connection.Dispose();         return dt;    }    protected DataTable BindToInventory()    {       DataTable dt;       dt = this.GetInventory();       this.DataList1.DataSource = dt;       this.DataBind();       return dt;    }    protected void Page_Load(object sender, EventArgs e)    {       if (!IsPostBack)       {         DataTable dt = BindToInventory();         DataTable tableSelectedItems =            this.CreateSelectedItemsTable(dt);            Session["tableSelectedItems"] = tableSelectedItems;         }    }

4. Run the application to make sure it works. That is, it should connect to the DotNetReferences table and bind the DataList to the table from the database.

   The GetInventory and BindToInventory methods are called by the Page_Load method. How often is Page_Load called? Every time a new page is created—which happens for every single HTTP request destined for the UseDataList page. In the case of running this application on a single computer with one client (in a testing situation), perhaps connecting to the database for every request isn't a big deal. However, for applications expecting to serve thousands of users making frequent requests, repeated database access actually becomes a very big deal. Accessing a database is actually a very expensive operation. As we'll see shortly, it may take up to a half second to simply connect to this access database and read the mere 25 rows contained in the DotNetReferences table. Data access can only get more expensive as the size of the tables in the database grows. A half-second in the computer processing time scale is eons to the program.

   Now think about the nature of the inventory table. Does it change often? Of course, not in the case of this simple application. However, think about how this might work in a real application. The items carried within an inventory will probably not change often (and such changes will probably occur at regular, predictable intervals). If that's the case, why does the application need to hit the database each time a page is loaded? Doing so is certainly overkill. If you could take that data and store it in a medium offering quicker access than the database (for example, the computer's internal memory), your site could potentially serve many more requests than if it had to make a round-trip to the database every time it loads a page. This is a perfect opportunity to cache the data.