Hi Rick,

Ok, I should have said MTDLLs seem like they are truly multi-threaded. <g> Really though, thanks for the clarification and extra info. I was referring to the ability to run multiple objects simultaneously in a single runtime environment. I can definitely see potential issues with this. I think that explains why the Session class came along at the same time as the MT runtime.

In my testing, tables in the default data session stay open between hits, if you leave them that way. Of course, considering that you could have two objects running simultaneously, you'll generally want each to have their own data session. Public variables/objects also stay in memory. So you could set up something like an application object once and reuse it on subsequent hits.

My main issue with MTDLLs at the moment is that my framework application object uses commands unsupported by the MT runtime. I'm also not all that crazy about accessing objects through COM.

Thanks again for the info.

>
>Nope. MTDLLs are no more multi-threaded and EXE servers in the true sense. What happens behind the scenes is that COM isolates each instance of the object on a separate thread and VFP stores all of its local stored state in Thread Local Storage. But there's no binary multi-threading where the same code in memory is run by different threads. This is a simulation of multi-threading that happens through some fancy footwork of the COM subsystem. Objects load and unload on each hit, although the runtime is cached through some COM tricks (extra COM references which basically locks it into memory - this is why you can't unload a VFP COM server after having been loaded into ASP/ASP.Net).
>
>There are also downisdes to this like two components on the same thread share the same VFP instance and environemnt, which maybe good or bad depending of how your components are designed.
>
>EXE servers get a bad rap, but there are a number of important benefits that you just can't do with DLL servers:
>
>* Manage the server remotely (start, stop, hold, update etc)
>* Recover from failures
>* Keep state
>
>All of these are related to the fact that EXE servers are external to the calling process and can be monitored and managed through the ISAPI interface (or through an external watcher application). DLL servers are hosted inside an uncontrolled aplication (IIS).
>
>In fact if you look at the architecture of ASP.Net you'll see that it uses Out of Process components (not with COM, but named pipes in this case) that to do exactly that - an external process that can be managed is controlled by a small ISAPI extension. This is smart design as it amkes it posssible to put metrics and maintenance smarts into the server so it can fix itself on failures and allow things like automatic updates without shutting the Web server down. Heck, that's the way Unix has been doing server design since the eaerliest times of server applications (daemons).
>
>All that said, MTDLLs work well, and they are very fast in loading etc. and they've gotten faster yet with IIS 6. But the load speed is also diminished by the fact that you have to re-establish your complete environment on every hit, you can't leave tables open or connections established which overall causes more slowness than any COM overhead might. If you have an application with large VFP tables or tables that sit on the network your performance will be crippled by the requirement to re-open tables on every hit.
>
>OTOH, these days performance is not nearly as much as an issue as it used to be. Today the hardware is so fast that all but the biggest applications cause a server to not be able to handle traffic on a single box. The big exception to these things are CPU heavy applications and in those VFP in general is a problem, and the overhead of calling a MTDLL or EXE component is not an issue in the first place.