Address space of DLLs called from classic ASP

Question

My application consists of a VB6 DLL that is called from ASP. It needs to manage a pool of connections to a (non-standard) database. I implemented this by using a global variable, but this is being reset every 20 minutes due to an ASP setting causing the application to crash.

A previous poster said that DLLs in ASP are all created in their own address space, thus making global variable solutions completely unworkable, as each page access would have its own ‘globals’.

That doesn’t fit with my observation that globals seem to exist until the DLL reaches its idle timeout.

Which of us is right? What scope can I assume on DLL globals?

Answer 1

The idea that each request would get its own copy of the global variables is False.

However it is strongly recommended that you compile VB6 dlls for use in asp as apartment threaded and with the retain in memory setting.

Each thread will get its own copy of the global variables. Hence multiple requests will not necessarily see the same global variables if those requests are run on different threads.

In observing IIS6 I noticed that in test situations where there is rarely multiple request running at the same time the same thread gets used for subsequent requests. I suspect that this may be the reason it appears to you that you have a single set of global variables. In production this is not going to be true.