>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.

The VFP Runtime's bulk stays loaded but your object's thread local storage and memory buffers do not. Hence I said 4 megs for the first hit 600-700k for any successive ones.

The reason the runtime is cached is because ASP does an extra AddRef on any object loaded for the first time. This is also why you can't release objects.

Still the overhead is there - if you try that do nothing object you can see the behavior. If you do the same with a light weight ATL component none of that happens.

>
>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?

You have to implement sessions on your own. It's quite easy using tables. Web Connection has a table based Session object built in.

>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?

It's possible but not efficient. Application variables should never be used with
VFP objects or any object that is not truly multi-threaded (binary multithreading like C++). Application var access with Apartment Model object is always queued to a single thread so no concurrent processing can occur. One thread for *all* ASP Application scoped Apartment Model objects. The restrictions are similar if you use Sessions to persist VFP objects but then the threads are tied to the user session and any other session that's tied to that same thread.

Take a look at the MSDN section for Object scope.