Storing Session State Out-of-Process with a StateServer
One technique you can use to store session state variables out-of-process is to use a state server. The .NET Framework includes a Windows service called the ASP.NET State Service that allows you to manage session state out-of-process. You start the ASP.NET State Service by running the following statement at the command prompt.
net start aspnet_state
|Figure 2: The Services dialog box highlighting the ASP.NET State Service.|
You can also start the service by clicking Start, choosing Settings, selecting Control Panel, choosing Administrative Tools, and finally selecting Services to launch the Services dialog box (see Figure 2
Double-click the ASP.NET State Service entry and specify manual or automatic. With the ASP.NET State Service running you can specify that your site should use it to manage session state by changing the sessionState
mode setting in the Web.config
Once you've made this change you can stop and restart IIS and now the ASP.NET State Service will handle state management duties. IIS looks to the stateConnectionString
setting in the Web.config
file to determine which server and port to connect to. The example above uses the default local server and port. You can easily change these settings to point at a completely different server.
Storing Session State Out-of-Process with a SQL Server
|Figure 3: TempDB contains the ASPStateTempActions and ASPStateTempSessions after running the InstallSqlState.sql script.|
You can also use Microsoft SQL Server to store session state out-of-process. This works the same way as the StateServer technique except state information is stored in a SQL Server database. The advantage to this approach is that you can cluster multiple database servers and if the one currently managing state fails another can take over the load.
You need to complete a couple of preparatory steps before you can begin storing session state in SQL Server. First you need to run either the InstallSqlState.sql
script. You'll find these scripts located in the \Windows\Microsoft.Net\Framework\v1.1.4322
(or later) file folder. The difference between these two scripts has to do with where the ASPStateTempApplications and ASPStateTempSessions tables are created. The InstallSqlState.sql
script creates them and other database objects in the TempDB database (see Figure 3
) while the InstallPersistSqlState.sql
script creates the ASPState database (see Figure 4
) and stores the tables there. The advantage of storing session information in the ASPState database instead of in TempDB is that you won't lose session information if you need to reboot the SQL Server machine.
|Figure 4: ASPState contains the ASPStateTempActions and ASPStateTempSessions after running the InstallSqlState.sql script.|
Next you need to modify Web.config
to change the sessionState
mode and sqlConnectionString
The advantage to either of the out-of-state process techniques (StateServer or SQL Server) to managing session state is that they are both very scalable. Both techniques will work whether you're running a single sever or grow into a multi-Web server Web farm.
ASP.NET 2.0 State Management Features
ASP.NET 2.0 will introduce the ability to use a session state data store other than SQL Server. This will be of interest to shops that need to take advantage of the ability to store session state information in a databaseOracle or DB2 for examplebut don't have any experience with SQL Server.
ASP.NET 2.0 will also introduce the ability to replace the default session ID generator with one of your own so that you can generate your own session IDs.