The Session cache is an instance of the HttpSessionState class. Instances of this class are accessible through a Web Page or an HttpContext object and are useful when building ASP.NET Web Applications.
The Session cache is a name and value dictionary capable of storing any data that can be serialized-converted into an XML representation. Simple data can easily be stored in the cache, and classes that implement ISerializable or use the SerializableAttribute can be stored in the Session cache. The kind of data that you store in the Session cache is data that is particular and relevant to a single session. Think single user or per-user information.
There are two general ways to manage the Session state and three specific ways within the two general categories. The first general category is in-process Session storage, and the second general way is out-of-process Session storage. In-process session caching stores information in the aspnet_wp.exe worker process and is usually lost if IIS or aspnet_wp.exe is recycled. However, in-process Session management is very fast and easy to use. The two out-of-process Session servers are the aspnet_state.exe (ASP.NET State Server), a Windows Service application, and MS SQL Server. The two out-of-process servers are slower but more reliable, capable of withstanding IIS and aspnet_wp.exe restarts, and they are capable of being used in multi-processor, multi-computer Web farms. You can also configure the out-of-process servers on a separate machine from the one running Internet Information Services.
In this article I will discuss the steps you need to take to configure each server. Using Session is the same regardless of the server. You simply index the Session cache with a key string and store and retrieve serializable data in the cache. The kinds of data you will store in the Session cache is up to you, but you will more than likely want to use the Session cache to store information that spans multiple pages. The classic example is the shopping cart. Without further ado, let’s proceed.
Reviewing Default Session Configuration
By default ASP.NET Web Applications are configured to use in-process Session state caching. This happens for the simple reason that the project template for ASP.NET Applications contains a Web.config file configured to do so. Thus, when you create a new ASP.NET Web Application the CSharpWebAppWiz folder contains a Web.config file that is copied into your new project. In addition, the Machine.config file is configured for in-process Session management. Listing 1 shows you the portion of a Web.config file that is used to configure Session management.
Listing 1: The sessionState tag in a Web.config file, used for Session state management.
<sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;user id=sa;password=" cookieless="false" timeout="20" />
The tag is <sessionState>. The mode indicates which kind of Session state server to use. The stateConnectionString is used specifically for the ASP.NET State Server, and the sqlConnectionString is used when state is managed through SQL Server. The cookieless attribute indicates whether cookies are used to store the Session ID, and timeout indicates the amount of time (in minutes) the object will remain in the Session cache before it is dropped.
For in-process Session we use the case-sensitive mode value of InProc, and the cookieless and timeout attributes apply. The other values for mode are Off, StateServer, and SQLServer. Off indicates that Session caching will be disabled; StateServer indicates that we are using the ASP.NET State Server application aspnet_state.exe, and SQLServer indicates that Session information will be cached in an instance of MS SQL Server properly configured for this purpose.
The timeout property is pretty straightforward. If you don’t access an item in the cache and the timeout period elapses, then the item is flushed from the cache.
Configuring the Session State Server
As you now know ASP.NET Web Applications will store information that you put in the cache in-process. The process referred to by in-process is the aspnet_wp.exe worker process. If you want to store the Session data out-of-process because you need a more reliable Session then you can use the ASP.NET State Server. The State Server can be running on a remote machine and can withstand IIS and aspnet_wp.exe restarts.
To use the State Server you have to perform at least two steps: you have to change the mode attribute to StateServer, and you have to start the ASP.NET State Server service. Simply replace the text “InProc” with “StateServer” in the Web.config file to change the mode. To start the service you can open a command prompt and type “net start aspnet_state” without the quotes to start the service. (Type “net stop aspnet_state” to stop the service.) Of course, if you want the service to start every time you reboot then you will want to open the Services section in Computer Management (see figure 1) and change the ASP.NET State Service from Manual (shown in the figure) to automatic.
Figure 1: Change the ASP.NET State Service to automatic to ensure it is running each time your computer starts.
The last piece of the puzzle is the stateConnectionString attribute. By default the stateConnectionString is configured to run on the computer containing the Web.config file on port 42424. If you want to cache Session information on a remote computer then you will need to change the IP address to the IP address of that remote computer.
After you have configured the State Server you can experiment with it. One test is to stick something in the Session cache, restart IIS, and determine if the item is still in the cache where you left. You will be pleased to see that it is. For intranets and simple Web applications you can safely use the in-process cache. However, if you need or don’t want users to lose their place then consider using the State Server.
Configuring MS SQL Server for Session Caching
Finally we come to MS SQL Server. SQL Server is the big gun of Session caching. Using SQL Server for Session caching should afford you the maximum scalability and reliability, but you are writing to a database each time you use the cache. As a result SQL Server will likely yield the worst performance. Use SQL Server when the data must be maintained and you have lots of horsepower. (You can use MSDE (Desktop SQL Server) during development and testing on your PC too.)
To configure and use SQL Server we have to complete some basic steps. First you will need to ensure that you have access to a SQL Server instance. You will also need to locate InstallSqlState.sql. This script is installed with the .NET Framework in C:WINNTMicrosoft.NETFrameworkversion, where version represents the version of the framework you are using, by default. You can run this script with a tool like isqlw.exe or SQL Server Query Analyzer.
When you run the script it will create a database named ASPState containing stored procedures for moving cached data in and out of a database. When you actual place information in the cache it will be written to tempdb-the temporary database. You can run the script, store information in the Session cache, and view the tempdb database tables ASPStateTempApplications and ASPStateTempSessions to see how cached information is stored in the database.
If you elect to stop using SQL Server then you can remove the database and tables for caching by running UninstallSqlState.sql.
Session caching can significantly improve the performance of your Web applications. Experiment and use the state server configuration that is right for you.
Consider sticking with the default configuration and in-process state management for applications where it is suitable for users to lose their place if IIS recycles. If the data has to be resilient under the most strenuous circumstances then use the ASP.NET State Server or configure MS SQL Server to store your state information.
About the Author
Paul Kimmel is a freelance writer for Developer.com and CodeGuru.com. Look for his recent book “Advanced C# Programming” from McGraw-Hill/Osborne on Amazon.com. Paul will be a keynote speaker in “Great Debate: .NET or .NOT?” at the Fall 2002 Comdex in Las Vegas, Nevada. Paul Kimmel is available to help design and build your .NET solutions and can be contacted at email@example.com.
# # #