The ASP.NET Framework provides many server-side caching techniques for developers to persist data based on the scope. We also have dedicated server caching server techniques like for the ASP.NET session state server (SQL Server Only) or any custom implemented solutions (any other DB).
The following are the out-of-the-box server-side techniques available based on needs.
1. Request level cache
Any request initiated by an ASP.NET application will travel through the HTTP hive; it will create quite a number of HTTP objects and out of all the HTTPContexts is the major object for any request life cycle.
A HTTPContext has an Items property, a IDictionary object and a place to save data that is relevant or scoped at the request level. Data cached at this scope will be wiped out after the request completes. The IDictionary object is not strongly typed. So before retrieving from the IDictionary the casting of the data must be done as in the following:
HttpContext.Items["userName"] = "Srihari";
HttpContext.Items["empID"] = 1779;
string empName = (string)HttpContext.Items["userName"];
int empID = (int)HttpContext.Items["EmpID"];
2. User level cache
The ASP.NET session state allows the caching of the data that can be accessed across requests, while the request level is not, but scoped only for the specific user. Again Session is a property of a HTTPContext object and unlike the Items object, it is not strongly typed. Data cached at the session scope will be lost. Based on the web.config file configuration, the default is 20 minutes; when there is no user activity on the application, or when the user uses ASP.NET session functionality.
HttpContext.Session["userName"] = "Srihari";
HttpContext. Session["empID"] = 1779;
string empName = (string)HttpContext. Session["userName"];
int empID = (int)HttpContext. Session["EmpID"];
<system.web>
<sessionState timeout="60" />"
</system.web>
The default location of the session cache is "in-memory". The other location can be an ASP.NET session state server, either in the same box or a new server altogether. The later one supports session sharing, even after a client machine reboot since it is saved in the separate server, actually in SQL Server tables.
Also .NET supports the implementation of the new custom solutions by extending the existing framework or to develop an altogether new mechanism.
3. Application level Cache
The ASP.NET framework has the HTTPApplicationState class that supports the saving of the data at the application scope. It can be accessed using the HTTPContext.Application property, again, similar to Items and Session, but scoped at the application level. Anything stored in this object is live until the application recycles; or the IIS worker process re-cycles. Saving a large amount of data will hinder the application performance.
Application["ApplicationStartTime"] = DateTime.Now;
DateTime _appStartTime = (DateTime)Application["ApplicationStartTime"];
Unlike Items and Sessions, an Application object is also not strongly typed so casting is necessary.
4. ASP.NET level cache
The ASP.NET level cache is similar to the application level cache in scope but can be accessed from HTTPContext.Cach. The differences are that data stored can have additional characteristics.
- Item expiration
When an Item is added to the cache it is possible to set how long the item can be available in the cache using a timestamp. Again, this timestamp can be either of two types, one is a relative expiration and the other is absolute expiration.
A relative expiration specifies that if an item should expire a certain amount of time after it was last accessed. Assume a cache item with a relative expiration of 20 minutes and the application continuously accesses the item every few minutes then the item should stay cached indefinitely. The moment the application stops accessing the item for at least 20 minutes, the item will expire.
Absolute expiration specifies that if an item expires at a specific moment in time, regardless of how often it is accessed.
- Item invalidations
ASP.NET provides the ability to invalidate cached items, when some other dependent elements, like application variables, file system files, or some database table column changes. So, when the element that a cache item depends on changes, ASP.NET removes the item from the cache.
The following are the dependency types that we can use in the code:
- Aggregate: This type combines multiple dependencies, via the System.Web.Caching.AggregateCache dependency class. The cached item is removed when any of the dependencies in the aggregate change.
- Custom: The cached item depends on a custom class that derives from System.Web.Caching.Cache Dependency.
- File: The cached item depends on an external file and is removed when the file is modified or deleted.
- Key: The cached item depends on another item in the application cache, referred to by its cache key. The cached item is removed when the target item is removed from the cache.
- SQL: The cached item depends on changes in a table in a Microsoft SQL Server database. The cached item is removed when the table is updated.
- Reclaim when memory is low (Scavenging)
Scavenging is the process of deleting items from the cache when memory is low. The items that are removed are typically those that have not been accessed for quite some time, or that were marked as low priority when they were added to the cache.
ASP.NET uses the CacheItemPriority object to determine which items to scavenge first. In all cases, ASP.NET provides CacheItemRemovedCallback to notify the application that an item is being removed.