>Larry,
>
>As I mentioned to Claude, MTS is not an option. I am dealing with a large stateful component that is contained in an out of process EXE server. Unfortunately I don't have the time or budget to rewrite the component as an MTDLL. So I am looking for some other way to create a pool of these servers and manage access to them.
>
>-Charles

Charles,
IMO, you would not need to rewrite them at all unless you have a lot of UI functionality built into the COM object. If not and you compile it as a MTDLL, you could add it to MTS/COM+ with very little effort (see Craig B. series on COM+ applications in FoxTalk - www.pinnaclepublishing.com/ft a couple of months ago).

MTS/COM+ applications do not have to be stateless. It is recommended but not a requirement. If you issue a SetComplete or SetAbort, the object goes out of scope as far as MTS/COM+ is concerned. It is recommend that you issue one command or the other at the end of every method (or at the end of the top method that calls many internal methods). However, if you only issue this in the Destroy event of your object, MTS/COM+ will keep your object active indefinitely (until you release it in the outside world). You will get a reference to the same object for every call and you will be able to store values to properties and have them persist.

Because MTS/COM+ caches things, instantiation should be faster than a simple standalone object. You will have to test this if you decide to go this route.

HTH. Good luck!