You might have noticed that at times, it appears that IIS6 is losing or dropping your ASP.net session information. After looking around under the hood of IIS, there are a couple settings in IIS6 which can affect the consistency of session data.

In case you’re not already aware, IIS has two different mechanisms to handle ASP.net session information:

• In ProcessWhen using the in process method for session storage, IIS places your session data in the same memory area as the ASP.net worker process which is servicing your site. Since the session information is being stored in the worker process, if your ASP.net application is reset for any reason – the session data is lost at the same time.
• Out Of ProcessConfigured using out of process means that the session information is stored in a different worker process, either on the same server or on a different server to that running the ASP.net application. As you’d expect, if the ASP.net application is restarted for whatever reason – the session data is not lost. Within this type of session management, there are two physical methods you can choose:
  • IIS State ServiceIIS6 comes with a Windows service which can be used for session storage. You can configure it to run on the same server as your application to support a web gardens (even when you only use a single worker process) or on a different server to support a web farm (though, you could do that with a single server as well if you wanted I believe).
  • SQL Server

  As with the IIS State service above, utilising SQL Server to store session data can be done locally or on a remote server.

  One point of interest about using out of process storage, is that if you’re storing rich objects and not simple primitives (int/string/float/..) then you’re objects must be serializable.

If your ASP.net site utilises out of process session management, then you really don’t have a lot to worry about. If on the other hand your site utilises the default configuration, which is in process management, then you have some important points to be aware of.

Application Pools

One of the new options within IIS6 is a feature called an application pool. An application pool is a way to isolate a web site or collection of, from other web sites. This isolation is created by each application pool having its own worker processes. Of course, if you’re using in process session management then each application pools session data is also isolated from another.

For convenience, a virtual host in IIS6 can contain as more than one application within it. If you are not aware of the impact of creating applications, then it is very simple for your ASP.net site to be serviced by more than one worker process. Of course, when that happens and a clients request is bounced between multiple worker processes; their session data is ‘lost’ for the first request in each process. From that point onwards, it exists however updating a session object in one process does not update it in the other, leading to inconsistent application execution.

Web Garden

A web garden is a small scale web farm (har har!) which allows multiple worker processes to service a single application pool on the same server. Since each worker process has its own memory for storing session information, you’ll run into issues using a web garden and in process session management at the same time.

Recycling Processes

IIS also provides a convenient way of recycling worker processes systematically. A lot of web hosts will use this feature to cycle processes daily in the early hours of the morning to keep the memory use of each worker process to a minimum. Of course, if you’re application is using in process management – this feature would destroy any active session data being stored. This might seem trivial, however it would be extremely frustrating to have a worker process automatically cycle while you were half way through filling up your online shopping cart.

Simple Solutions

If you happen to have multiple applications running within a single site, you can force each application to use the same application pool. By doing so, each application will be served by the same worker process (assuming you are not using a web garden) and thus all of your applications can share session information seamlessly.

If you’re using a web garden at the moment and you’re application doesn’t receive enough load to require the other worker processes, reducing it back to a single process will stop you ‘losing’ session information. If you require the other worker processes, then you don’t have a choice but to use an out of process storage mechanism. If you don’t want to use the state server or SQL Server, you could alternatively roll your own as well.

Unfortunately, if you’re using in process session storage you don’t have a leg to stand on when a worker process is recycled. If you are using any out of process mechanism, either the two listed above or your own custom version – you should find that your session information is perfectly safe whilst cycling processes.

Happy session management!