>>MTDLLs aren't truly multi-threaded. They are STA threaded components and COM calls them from different threads and isolates the threads providing a simulation of multi-threading. THis is why you can't create multi-threaded code from VFP directly - you need a multi-threaded COM client calling into VFP to provide this functinality.
>
>I note when I look at my Task Manager - there are a bunch of SVCHOST running - some using a lot of memory and some using less. Would multiple requests for a VFP MTDLL also show multiple VFP instances in the task manager with varying degrees of memory consumption?

It depends on how your Web Server is set up but in any of the non-low Isolation modes IIS will use SVCHOST to host any COM objects it loads. So teh VFP runtime lives inside the SVCHOST applications.

>It almost seems that STA's - even on the "user's" desktop are the norm. XP seems to do a more efficient job of loading and managing them than earlier versions.

Most COM objects are STAs - VB 6 was STA model. For desktop apps there's no reason you'd ever need anything but STA. On server apps, STA has a fair overhead, but again this is very relative. In light of data access overhead for STA is pretty reasonable.

>So why did MS promote the VFP MTDLL if it is so "useless"? There has to be a reason beyond marketing something that "isn't" to us muggles behind the benches.

It isn't useless. It works well as long as the client is multi-threaded and well behaved. Performance is good although in IIS you do have the isseu that VFP loads up on every hit (ie. everything unloads and reloads including tables needing to be reopened and objects reloaded on every hit). Still perf is pretty good...

And as long as your app works and is well behaved. The biggest problems with this model are: If you crash an STA COM component (with a C5 which unfortunately happens with VFP from time to time) you will likely hang the application. The app will continue to run but the COM component will be crashed inside of the service adn there's no way to clean up. Depending on how bad the crash is it might take the Web Server (or the hosting application) down with it or it might just stay loaded and not be working.

COM is messy any way you look at it. It is too with Web Connection, BTW. The one difference is that Web Connection tries to manage the VFP COM objects for you so it can tell if things go wrong and automatically handle failures by reloading components as needed. But for config and true multi-threading it's no better (or worse) than MTDLL - like STA, Web Connection uses a hack (a pool manager) to provide a simulation of multi-threading.

This is really the reason Microsoft now has .NET - because COM was not a super stable technology in this multi-threaded Web Server environment. It does away iwth the STA model and instead uses true multi-threaded components which is more efficient, less resource intensive and less prone to lockups.

.NET addresses the key problems with COM:

* easy installations (just copy files with the server running)
* easy debugging (for development this is key!)
* full multi-threading support
* much lower resource usage (for the system management) on requests


+++ Rick ---