Session state and garbage collection in IIS6 for Classic ASP

Question

This is a bit of a throwback question, and probably relatively fundamental, but I'm at a loss.

How does IIS manage Classic ASP session state?

We have an app that stores user information in session, and when many users are using the app, it seems to be recycling session for users, even though the "expire period" has not elapsed.

We suspect that when a certain amount of memory has been used for the session state, it begins to recycle the oldest session objects or something like this.

If this is correct, is there some way to control for it with the existing application code?

Thanks!

Answer 1

ASP sessions are stored as simple in memory COM objects when the process hosting the ASP application are terminated so will all the sessions.

ASP does not "recycle" active sessions. However there are number of other circumstances which can affect ASP sessions.

Application Pool Idle Timeout

One phantom reason "Sessions" appear to timeout prematurely is because the "Sessions" in question are just under test during development. Hence whilst the developer is examining the content of a page or reviewing some code no further requests hit the site since its not actually a live site.

In IIS manager open the properties of the pool in which your ASP application runs. Take a look at the Performance tab. The Idle Timeout will default to 20 minutes. Hence if you have specified a session timeout of say 60 minutes and you are "testing" that timeout you actually discover your session has timed-out in 20 minutes. The lack of activity has killed the application pool.

Application Pool Recycling

IIS may recycle the application pool in which the ASP application is running in. Recycling means that the existing set of processes currently hosting the ASP application no longer accept new requests. New requests go to a new set of processes and the older processes will terminate when they have completed their outstanding requests.

There are a whole host of different settings and criteria that can be configured that trigger the recycling of an application pool. Take a look at the Recycling tab of the pool properties dialog.

If you think that there may be an excessive demand for memory then the Memory recycling section may indicate a cause.

Web Garden

An Application Pool can contain multiple processes to run the same set of applications. Back on the performance tab note the Web Garden section at the bottom. By default this is set to 1. However multiple worker processes will play havoc with ASP sessions. As noted above ASP session are simple in-memory COM objects. If subsequent requests for a specific session are dished out to different workers one worker will not have access to the session object that the other has.

Session.Abandon or Session.Clear

Logic bugs can sometimes be the cause of sessions apparently disappearing. Calling the above methods at an inappropriate point in a sessions life can cause a problem.

Answer 2

I have experienced the same thing. Session seems to be emptied of the data, meaning that no variables is no longer stored in the session, but since the session exists, On_SessionStart doesn't trigger.

Gives you a headache if you initialize data for a visitor that you later on depends on...

I have considered this a bug that no one seems to know about, and haven't found a solution to it. It seems related to memory-usage, as you point out, and the solution seems to be to make sure you don't have any leaks.

http://stackoverflow.com/questions/1255980/implement-object-caching-in-classic-asp-memory-leaking