Session State and Garbage Collection in IIS6 for Classic ASP

Question

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

How does IIS manage classic ASP session state?

We have an application that stores information about a user in a session, and when many users use this application, it seems to be a reprocessing session for users, although the expiration has not expired.

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

If this is correct, is there a way to manage it using existing application code?

Thanks!

Answer 1

ASP sessions are stored as simple in COM memory objects when the process hosting the ASP application ends just like all sessions.

ASP does not activate active sessions. However, there are a number of other circumstances that can affect ASP sessions.

Application Pool Timeout

One of the phantom Sessions reasons is showing up prematurely because the Sessions in question are just being tested during development. Therefore, while the developer is studying the contents of the page or looking at some code, further requests do not get to the site, because in reality it is not a live site.

In IIS Manager, open the properties of the pool where your ASP application runs. Take a look at the Performance tab. The default timeout will be 20 minutes by default. Therefore, if you specify a session timeout of, say, 60 minutes, and you “test” this timeout, you will actually find that your session has a timeout after 20 minutes. Inactivity killed the application pool.

Recycle Application Pool

IIS can reuse the application pool in which the ASP application runs. Disposal means that the existing set of processes currently hosting the ASP application no longer accepts new requests. New queries move to a new set of processes, and old processes stop when they complete their outstanding queries.

There are a number of different settings and criteria that can be configured to start application pool recycling. Take a look at the Recycle tab of the pool properties dialog box.

If you think that there may be an excessive need for memory, then the memory utilization section may indicate the reason.

Web garden

An application pool can contain multiple processes to run the same set of applications. On the Performance tab, notice the Web Garden section below. By default, this value is 1. However, several workflows will play havoc with ASP sessions. As noted above, an ASP session is a simple COM object in memory. If subsequent requests for a particular session are displayed to different employees, one employee will not have access to the session object that another has.

Session.Abandon or Session.Clear

Logical errors can sometimes cause sessions to disappear. Calling the above methods at the wrong point in the life of the session can cause a problem.

Answer 2

I experienced the same thing. The session seems to be freed from the data, which means that no variables are stored in the session anymore, but since the session exists, On_SessionStart does not start.

It gives you a headache if you initialize the data for the visitor, which you later ... depends on ...

I examined this error, which no one knows about, and did not find a solution for it. This seems to be related to memory usage, as you point out, and the solution seems to be to make sure you have no leaks.

Implement object caching in a classic ASP leak

Answer 3

This problem turned out to be the number of workflows on the Performance tab for me. For some reason, it was set to 2. We returned it to 1, and the problem disappeared.