>
>User1 loads up your COM object and uses it and then stops using it (leaves
>the web page or releases it from VFP/VB/etc). The init method fires for
>this user, your custom methods fire, and then the destroy method fires.
>But the pool manager (FoxISAPI or MTS), instead of actually releasing the
>object from memory, keeps it in its RAM pool.

MTS doesn't work that way. It won't pool objects - it relies entirely on client connections to perform any lifetime management unless you use transactions and JITA, which is actually really inefficient for VFP objects.

>
>User2 loads up your COM object and uses it and then stops using it. The
>init method won't fire because the app object has already instantiated.
>Your custom methods will work - but maybe not if there is path
>information that gets setup in the INIT. The destroy method fires. The
>object goes back in the poool.

Multi-instance DLL objects will fire their Init on every instantiation. If they didn't you'd be screwed because you'd never get a chance to initialize the environment.

The only time when Init/Destroy are shared is is with multi-instance EXE servers because you end up with one physical instance that's shuttled between references.

+++ Rick ---