Hi Rick,

I thought that in-process COM DLL's were not reloaded with every hit, but were loaded one time only and stayed resident. My understanding of the MT VFP DLL is that there is some memory allocation overhead with each creation of the object because it needs to set up quite a bit of global storage. But the DLL itself remains resident, and object creation (after the first one) is relatively fast.

In your book, I could not find much on how the WC/FoxISAPI approach deals with session management. Can you elaborate a bit on that?

Finally, I was wondering: Is is possible, using ASP, to create several instances of an out-of-process EXE server just like you do with FoxISAPI, but instead use the application startup event and store references to those objects in application variables? It seems that keeping an object reference alive at the application level would keep the object from unloading. Furthermore, it seems that that within ASP (using application.lock to manage the strategy) you could coordinate round-robin access to whichever COM object is not busy. What am I missing?

Thanks very much.