>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've never been able to get array returns to work reliably. This is most
likely what your problem is. There's a simple workaround though: Return
a single object that has an Array member. This works fine - I have several
VB apps that call VFP InProc COM servers in this fashion and it works well.

>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.

Take a look at the Active Server Documentation and look at how objects are
instantiated. In 5.0 EXE was the only way you could run VFP objects reliably,
because of the problems with the overlapping globals in 5.0. It was a bad
idea, which is why I have to date never installed a live ASP application that uses VFP COM objects.

EXE Servers loaded off Server.CreateObject cause a global lock on the COM
object manager in the Server object which means while your method is running
it's locked and can't do anything else.

Not sure what you mean by CreateObject on its own. I don't think that's supported (I may be wrong, but I think I actually did that by accident
last night).

>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.

Performance is hard to measure that way and I'm pretty sure it was serialized.
The only way to know for sure is write some code into your servers that check
for that by running a long and a short request in close succession and seeing
whether the short one returns first.

Either way. I find that worthless as well even if it did work - the overhead
of loading a new instance of VFP will kill your server with even minor load.

>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?

It's the way that the Server object works (at least that's the way it's
documented - I haven't tried this recently simply because it doesn't
really matter much). It doesn't spawn new threads - it runs a pool of
threads for COM objects, some of which are actually cached. Whenever
an EXE is encounter it looks the pool down. All object references you
get are indirect references (proxies) and the server object controls
the access.

>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?

It was mentioned in the bonus session I believe and I discussed it my
Web sessions.