>Amazing. Even shows some promise. However, I have a question after reading the documentation provided that may have a bit of an impact on us VFP guys. Read the following text:
>
>[start]
>Requirements for Poolable Objects
>Poolable objects must meet certain requirements to enable a single object instance to be used by multiple clients.
>
>Stateless
>
>Poolable objects should hold no client-specific state from client to client, to maintain security, consistency, and isolation. You can manage any per-client state using IObjectControl, performing context-specific initialization with Activate and cleaning up any client state with Deactivate.
>
>No thread affinity
>
>Poolable objects cannot be bound to a particular thread, otherwise performance could potentially be disastrous. For this reason, poolable objects cannot be marked Apartment model, they must run in the Multi-Threaded Apartment or the Neutral Apartment. In addition, poolable objects should not use thread local storage (TLS), nor should they aggregate the Free-Threaded Marshaller (FTM). Note that currently, the Microsoft Visual Basic development environment can only create Apartment model components. For this reason, Visual Basic components cannot be pooled.
>
>Aggregatable
>
>Poolable objects must support aggregation– that is, they must support being created with a pUnkOuter. When COM+ activates a pooled object it will create an aggregate to manage the lifetime of the pooled object and to call methods on IObjectControl. Note that currently, you cannot create aggregatable components using the Java language.
>
>Transactional components
>
>Poolable objects that participate in transactions must manually enlist managed resources. If your object holds a managed resource such as a database connection while it is pooled, there will be no way for the resource manager to automatically enlist in a transaction when the object is activated in given context. Therefore, the object itself must handle the logic of detecting the transaction, turning off the resource manager's auto-enlistment, and manually enlisting any resources that it holds. In addition, a transactional pooled object should reflect the current state of its resources in IObjectControl::CanBePooled.
>
>Implement IObjectControl to manage the object lifetime
>
>Poolable objects should implement IObjectControl, though it is not strictly necessary to do so. Transactional components that are pooled, however, must implement IObjectControl. They should monitor the state of the resources they hold and indicate when they can't be reused; when CanBePooled returns false it will doom a transaction.
>
>Language restrictions
>
>Currently you can write poolable components only in C++, due to the restrictions indicated above.
>[end]
>
>Now, unless I am wrong, despite the last statement, there is nothing listed here that would prevent a VFP SP3 developer from writing a poolable component, unless (a reasonable possibility) there is something I don't understand about TLS, FTM, or IObjectControl within the context of a VFP MTDLL. Can someone answer this question? And if we can write poolable components, shouldn't we get M$ to revise this document?
>

I don't know enough about COM+ or how COM is implemented internally in VFP to comment on this. However, if VFP cannot currently participate, I'm sure it will be modified to do this as COM+ is EXTREMELY important to MS. We need to remember that there are always lags between OS changes and applications that can take advantage of the OS improvements.