Thanks for the info. Yes this is the same sort of thing that you can globally do with ASP but it's a bit of a hack as it affects the entire machine and all COM+ packages. And because it's a registry thing it's very likely to be forgotten.
One's gotta wonder why this has been removed from COM+. When I asked this yesterday I looked in the package and component trying to see a setting. I do remember it being there in MTS a long time ago.
+++ Rick ---
>COM+ uses a thread-pool per server application, and the size of the STA thread-pool is approximately 10 threads multiplied by the number of CPUs. You can increase/decrease the size of the thread pool—see Microsoft Knowledge Base article Q303071.
>Also, under plain old MTS, which a vfp mtdll will use unless it's running under Low Isolation, there's a simple registry setting that determines how many threads are allocated for COM objects running in the mts process. This defaults to 25 x [# of cpu's]. So on a dual-proc server, you would have (25 x 2) 50 threads allocated by default, and you could adjust this setting yourself by going into the registry and changing the cpu multiplier from 25 to whatever.
>Even ouside of COM+ and MTS, you could use the AspProcessorThreadMax property if calling from ASP or ASP.NET.
>You're implying that this technology is hard to control or somehow dangerous and it's just not true...
>
>>>You can limit the number of threads used by using COM+. COM+ also allows more scalability when there's the need to put the DB on another server.
>>
>>I am not aware of that. How exactly? If you're talking about object pooling you realize that this doesn't work with VFP and STA components as it requires re-entrant objects.
>>
>>+++ Rick ---
