I wouldn't have dreamed of trying this stuff in VFP 5.0 - I have written COM objects in VFP 5.0 and I know how they serialize.

The problem that I'm having may actually be related to the fact that I return an object to the ASP page - which you should be able to do over the COM layer. The object is a "collection" - actually an array of objects. I'm going to try it returning simple data types instead to see if that's what's breaking it.
Regardless, if it serializes method calls it's still not going to be very efficient.

I got the idea of the single-use EXE from a message that you posted. I'm not sure what you mean by "all COM access siezes". I had to make a few changes to my code but I compiled it as a single-use EXE. Then I used Createobject (instead of Server.CreateObject) to create the objects.

What happened was interesting. Of course, I got multiple instances of my class instantiated (multiple EXE's in Task Manager). Performance for each call was a good deal slower on average, because of course each thread was instantiating it's own object from it's process. But it didn't seem like the method calls were serializing. Performance stayed the same or similiar from each client regardless of the number of copies of the library that had been loaded. When I ran a test of a page that essentially created and released the object 100 times from 3 different clients, all three took about the same amount of time (within 10 seconds). As well, if I had one of these processes running and I ran an interactive page that created and released the object once, it performed the same as if the process wasn't running.

Do you think it just appeared this way?

Why would COM access sieze if the thread spawned by ASP was creating it's own instance of the object in a separate memory space? I understand that the objects won't be "shared" but I'm not sure why they would conflict. Is there something fundamental that I'm not understanding about COM?

I'm curious how you did this (or maybe you didn't - I thought you mentioned something about it in an earlier message).

It's really frustrating that they shipped VFP 6.0 broken in this way. No one even mentioned this problem at DevCon. Did they just figure that we wouldn't get around to trying it out?

Thanks for your help and insight.

Eric Shaneson

>>The thing is that whether you like it or not, it seems that in IIS 4.0/ASP with Transaction Server installed mtx.exe (Transaction Server Explorer) hosts all of the threads that ASP spawns whether or not you have the package (DLL) registered with Transaction Server. Based on what you are telling me, the method calls should just be serialized, which is a big scalabilty drag but shouldn't break the app. Yet ASP seems to break!
>
>That's not correct...
>
>If you have VFP 5.0 and you have your objects marked for multi-use (the only
>way they will run in MTS) you're corrupting global memory in each instance.
>VFP *will* load multiple instances but they'll thrash each other.
>
>In VFP 6.0 you'll also load multiple instances, but they will block and
>will not corrupt each other's global data.
>
>The bottom line is don't even think about running VFP 5 COM objects in
>MTS. Even with 6.0 it doesn't make any sense to do so unless you need
>some very specific features. It certainly won't buy you any scalability!
>
>If you're having the corruption problems with 6.0 then there may be
>other problems that I don't know about... as far as I've seen
>running 6.0 components in MTS is safe, but inefficient.
>
>
>>1) Figure out a way to serialize the method calls.
>
>You can't do that if you're using ASP.
>
>>2) Use out of process single-use EXE's (which will of course spawn entirely ne threads for each use). What is the overhead involved here? I know you can configure ASP to use out-of-proc components but I haven't heard much about how well it works.
>
>Those will serialize IIS in a much worse way. All COM access seizes
>while the VFP COM object runs.
>
>>3) Give up and wait for Service Pack 1. Any idea how long until release?
>
>Not for a while - VFP 6 just shipped.
>
>+++ Rick ---