Steve,

I don't think this will matter with the multi-threaded runtime. You'd get roughly the same performance with multiple same COM+ application objects running as opposed to separate ones. The reason has nothing to do with the runtimes (each COM+ application will load its own VFP runtime in most cases depending on how the package is set up), but simply that the threading model will deal with the simultaneous access issues.

I'm not sure why you think you might need multiple COM+ applications? I think the book mentiones the newer runtime and that it would allow multiple instances to run simultaneously (using MTDLLs).

+++ Rick ---


>Just a thought here after flipping through Rick's book for the 99e99th time.
>
>Under Win2K and VFP7, would it be worth it to
>  1 Create a project
>  2 Compile it 4 times as 4 different MTDLLs
>   with 4 different GUIDS/CLSIDS/ProgIDs
>  3 Register each one seperately in the same directory
>  4 Create a COM+ Server package for each
>  5 Set each one to "Leave Running When Idle"
>  6 Instance each one in a site's global.asa to get it started
>  7 Pick one at random to instance from any given ASP page
>
>On one hand, I was thinking that this would give more scalability because there would be 4 potential objects to service any request. One might get hit more than the other others, but it would be faster than having a single component service the whole site.
>
>On the other hand, I was thinking that this would convey no benefit because there is only one VFP7 runtime in memory at a time and it is single-threaded and one MTDLL will still block the others.
>
>And I wonder if that would make a difference with 2 or 4 processors.
>
>Could anyone comment?