Hi Christof,

>> an STA style thread has a lot more overhead and requires state that can easily get corrupted.
>
>What kind of "state" do you refer to here? Session state is managed in the process and can be accesed by STAs as easily as by MTAs. Apartments do have a state, but i haven't yet heard of any corruption.

STA Thread state. TLS specifically which must potentially be shuffled around if multiple calls are made to COM objects. ASP and ASP.NET both cache com references and if you use any kind of Session/Application state this problem gets even worse with the thread marshalling required.

As to corruption the problem is if you should crash a COM object, chances are very good that that COM object will continue to fail or fail to load after a hard VFP exception which results in a hung application at worst or an invalid response at best. ASP and ASP.NET don't recover well from COM crashes (and I don't mean a code error, but a C5 error which unfortunately happens from time to time).

>> It frequently blocks as it must ensure that the COM object gets called the same thread it was created on for succesive calls.
>
>Yes, ASP.NET blocks frequently on VFP COM calls.
>
>I'm not sure, however, in which way ASP.NET has to ensure thread identity.
A thread can either be STA or MTA. How object are called is managed by Windows itself, not by ASP.NET. Whether or not, successive calls end up on the same object, depends on how ASP.NET obtains a reference. I'm pretty certain that subsequent page requests are not routed to the same thread, just any thread that is available.

The main request runs on a single thread, yes. But if there's anything stored into a Session object for example or you fire off async threads from an ASP page (or you use an Async handler for that matter), then thread marshalling needs to kick in with the potential of dead locks. This is a bad idea for VFP objects to be sure...

Ok, that point is somewhat exaggerated because if you KNOW about it you won't do any of those things in the first place. But then of course we're back to the point of understanding the technology I mentioned to Claude...

Also, I have noticed in both classic and ASP.NET that somehow ASP tries to use some sort of thread affinity that's tied to the browser. Don't know how or why it does this, but in many cases the same thread will fire even on a busy server based on connection (keep-alive) settings.

>Whatever "strategic" is. <g> I agree, though, that picking either one is better than throwing too many tools at a single application. We probably would pick different tools, though. <g>

Yeah I know. AFP for you, ActiveVFP for Claude and Web Connection (or plain ASP.NET) for me; and well, that's the beauty of it. We all have choices and we can use what works best for all of us...

By strategic I mean an application that you design now and want to last a few years into the future. Not an application that now all of a sudden has to add a couple of Web features to support an existing VFP system, but an application that will take some serious time to develop. Point being that if you plan for the future and expandability my choice would definitely not be on .NET + VFP! It would be one or the other, but definitely not both!