ASP.NET gives you several alternatives for how the session data is stored on the server (remember that the clients just get a key to uniquely identify their session – not all the information is stored on their machines in cookies or anything).
- In Process
- State Server
- SQL Server
- Custom
These can be set by using the “mode” attribute of the “sessionState” element.
The “InProc” value (in-process) means that IIS stores the session state information within memory in the process that it uses for running the applications. This is the default setting and is ok for many situations, but it has some big downsides. All sessions are reset when the IIS process is recycled, which usually happens pretty randomly. Also, all sessions are reset if you do a major rebuild of the site (which can be more of a pain than you think, especially as ASP.NET might do this behind the scenes if you change something in the App_Code folder). The main advantage is that it is easy to configure and works out of the box. Another advantage is that the data in the session state variables doesn’t have to be serialisable.
The “StateServer” value means that ASP.NET should look in the “stateConnectionString” attribute to find a connection string to connect to an ASP.NET “state server”. A state server is a service which comes with ASP.NET (it doesn’t run by default – you’ll need to start it up and set it to run automatically when Windows starts). You can find it in the folder %windir%\Microsoft.NET\Framework\VersionNumber\aspnet_state.exe . Note that this doesn’t need to run on the same machine as IIS is running on, but it is probably sensible to run a state server of the same version as the version of IIS. I’ve never used this myself though, so I can’t tell you how well it works. The default connectionstring is to connect to the current server. I expect that this will need data to be serialisable and will be able to retain the data as long as the sessionstate service isn’t restarted (even if IIS is). It won’t retain data if the sessionstate service (or the whole server that it is running on) is restarted though.
The “SQLServer” option is my favourite. This looks in the “sqlConnectionString” attribute for a connectionstring to an instance of SQL server which is configured for storing session state information. ASP.NET 2.0 also added the “allowCustomSqlDatabase” element, which can be used to specify whether to use a customer SQL database instead of the default one. nb. You’ll need to setup SQL server for this, which you can either do by running the SQL script %windir%\Microsoft.NET\Framework\version\InstallSqlState.sql or by using the Aspnet_regsql.exe utility to do it for you.
The “Custom” value allows you to specify your own class which is responsible for storing state information. You’ll need to also add it to the providers section within the sessionState element and set the “customProvider” attribute to the name of the provider type. Your custom class will need to inherit from SessionStoreProviderBase.
There is also another value – “Off”. This turns off session state information being stored at all.
- ASP.NET Sessions Part 1
- ASP.NET Sessions Part 2 - accessing session state variable data
- ASP.NET Sessions Part 3 - Maintaining the Session Data Across Multiple Requests
- ASP.NET Sessions Part 4 - Configuring how the Session Variable Data is Stored on the Server
- ASP.NET Sessions Part 5 - How Long Does a Session Last?
- ASP.NET Sessions Part 6 - Abandoning a Session
No related posts.
Tags: .NET, ASP.NET, ASP.NET Sessions, Session, Sessions, SessionState, State