How Consumers Use Resource Pooling

To use OLE DB resource pooling, the consumer must obtain its data source object by calling IDataInitialize or IDBPromptInitialize to ensure that OLE DB services are enabled.

OLE DB services maintain resource pools of connected data source objects as long as a reference to IDataInitialize or IDBPromptInitialize is held or as long as there is a connection in use. Pools are also maintained automatically within a Component Services (MTS, if you are using Windows NT) or Internet Information Services (IIS) environment. To use OLE DB resource pooling outside of a Component Services or IIS environment, the consumer must keep a reference to IDataInitialize or IDBPromptInitialize or must hold on to at least one connected data source object. To ensure that the pool is not destroyed when the last proxy object is released by the consumer, keep the reference or hold on to the connected data source object for the lifetime of your application.

OLE DB services identify the resource pool from which the connected data source object will be drawn when IDBInitialize::Initialize is called. After the data source object is drawn from a pool, it cannot be moved to a different pool. Therefore, consumers should avoid changing initialization information. (Initialization information is changed by calling IDBInitialize::Uninitialize.) Pooling is also disabled if the consumer calls QueryInterface for a provider-specific interface prior to calling IDBInitialize::Initialize. Also, connections established with a prompt value other than DBPROMPT_NOPROMPT will not be pooled. However, the initialization string retrieved from a connection established through prompting can be used to establish additional pooled data source objects.

Some providers must create a separate connection for each session. These additional connections must be enlisted separately in the distributed transaction, if one exists. OLE DB services cache and reuse one session object per data source object, but if the consumer requests more than one session at a time from a single data source object, the provider may create additional connections and transaction enlistments that are not pooled. It is actually more efficient to create a separate data source object for each session in a pooled environment than to create multiple sessions from a single data source object.