.NET Data CachingBy Dimitrios Markatos
What is Data Caching?
In simple terms data caching is storing data in memory for quick access. Typically information that is costly to obtain (in terms of performance) is stored in the cache. One of the more common items stored in a cache in a Web application environment is commonly displayed database values; by caching such information, rather than relying on repeated database calls, the demand on the Web server and database server's system resources are decreased and the Web application's scalability increased. As Microsoft eloquently puts it, "Caching is a technique widely used in computing to increase performance by keeping frequently accessed or expensive data in memory. In the context of a Web application, caching is used to retain pages or data across HTTP requests and reuse them without the expense of recreating them."
In classic ASP we didn't have anything nearly as sophisticated nor as powerful as the ASP.NET caching API that is now available to us. With .NET we have the ability to cache whole pages (output caching), parts of pages or server controls (fragment caching) and data caching with the lower-level Cache API.
In this article I will be examining data caching in detail. For more information on output caching see Page Output Caching from the ASP.NET QuickStarts. For more information on fragment caching, see Page Fragment Caching from the ASP.NET QuickStarts.
Applications, Sessions and Cookies
While classic ASP does not have the rich data caching API found in the .NET Framework, it does give us the ability to maintain state and to cache data with the help of session, application and even cookie objects. For starters cookies, which are stored on the Web visitor's computer (disk) don't hold a lot of data. They have a 4k limit and can contain only string information. Additionally, a user may have their browser configured not to accept cookies. For more information on using cookies in classic ASP, see the Cookies FAQs on ASPFAQs.com.
Session variables can also be used to cache information in classic ASP, although, as with the cookie approach each session variable is specific to a particular user, and to tie a session variable to a particular user the user's browser must accept cookies. The advantages of using session variable's over cookies is that you can store objects, such as an array, or Dictionary object. Since session variables are stored on the Web server's memory, storing large objects in a user's session on a site with many simultaneous users can lead to reduced memory on the Web server. For more information on session variables see the Session Variables FAQs on ASPFAQs.com.
Most often application variables were the means one would use to cache information in classic ASP. Since a given application variable is "global" to the entire Web application, application variables are primarily candidates for caching information that is global across all Web pages on the site. That is, imagine that you ran an eCommerce Web site and that on every page you wanted to list the top 10 selling products. Rather than do a database access on every page, you could cache the results in an application variable. This is an excellent example of when an application variable would be a good use for caching. If you need to cache more user-specific information, such as the 10 most recently purchased items for the user who's visiting the site, you'd likely want to employ the session object or cookies to do this. (For more information on caching database values in an application variable be sure to read : A Real-World Example of Caching Data in the Application Object.)
You can use application variables for caching in ASP.NET much like you did in classic ASP. However, since ASP.NET Web pages can utilize the .NET data cache APIs there's really no reason to ever resort to using application variables for caching in an ASP.NET Web application. In fact, caching data through the data cache API as opposed to through application variables in an ASP.NET Web application has its advantages, including: items in the data cache will be evicted from memory if memory becomes scarce; when adding items to the data cache you can specify how long they should persist in the cache in terms of an absolute or slidign time; and many other advantages, which we will examine in this article.
So to sum up the use of Application, Session and or Cookie objects for caching in a classic ASP page:
- Use Sessions on a user-to-user basis as in an eCommerce site
- And use Application variables for site-wide information that doesn't require constant revision.
If you're interested in data caching in classic ASP, you can find more on that at Caching Data and Learn More About Caching. But we're here to show the incredible power .NET data caching has. While this article will focus on .NET data caching in detail, a good general article on .NET caching basics can be found here at Caching with ASP.NET.
Using Data Caching
The .NET data caching API is comprised of the two classes in the
System.Web.Cachingnamespace. The first class,
Cache, is the class we'll be using to add and remove items from the data cache. The second class,
To add an item to the cache you can simply do:
Note that the C# version uses brackets instead of parenthesis when referencing the items of the cache in the above manner. In the remainder of the examples in this article I will be using VB.NET syntax, but will point out any major differences between the VB.NET and C# syntax.
The above code adds the item
value to the data cache with the key
The key is used to reference the item at some later point. That is, in another ASP.NET Web page we
can extract the
value inserted above by using:
To explicitly remove an item from the data cache you can use the
specifying the key of the cache item you want removed:
Now that we've examined the simple form for adding, removing, and selecting an item from the data cache,
let's take a more in-depth look at adding items to the cache. In Part 2
we'll examine the
Cache.Insert method in detail, which can be used to enter cache items with
cache dependencies, absolute and sliding time expirations, eviction priority, and callback delegates.