What I'm saying is that you can't do this with ASP because ASP manage it's own private thread pool and you'd be stepping all over that. Using Sessions won't work because of the scalability issues.

If you use ASP, you have to stick to the ASP stateless model to get decent performance.


+++ Rick ---


>Rick, want we want is a pool manager that interfaces ASP scripts to multiple out-of-process EXE's. These (cloned) instances that would accessed, using the pool manager as the connector, from within an ASP script the way an in-process DLL VFP COM object is typically used. The pool manager would work like your version of FoxISAPI. The EXE's would always be loaded, they can be unloaded at will without stopping the server, their activity can be viewed in real time for debugging, etc. Same advantages as the technique you provide with Foxisapi/WC, but would be available/callable from ASP. As far as marshalling data between the out-of-processs EXE's and the ASP scripts... I dunno how complex that would be if going though a pool manager.
>
>>All I can say is this:
>>
>>Don't do that with VFP objects in ASP. You will only be able to call one object at time. The ASP Session object cannot be used reliably to pool apartment model COM objects because they have to maintain state.
>>
>>+++ Rick ---