Resource Pooling

Whenever the consumer requests a data source object from the provider, OLE DB services intercept the request, query the provider for supported information, and return a proxy data source object to the consumer. This proxy object appears to the consumer as if it were the provider's data source object. However, when the consumer calls methods to set data source properties, the property settings are cached in the proxy object and not used to set properties on the provider's actual data source object.

When the consumer calls IDBInitialize::Initialize, the proxy object looks for any initialized and connected data source object that matches the specified connection information and is not already in use. If such a data source object is found, rather than create a new data source object, set its properties, and establish a new connection to the database, the proxy object uses the existing data source object.

If a matching data source object does not already exist, the resource pool creates one. Immediately after initializing the new data source object, the resource pool creates a session object and caches it internally. The first time the consumer requests a session, the proxy object returns this cached session object.

When the consumer releases the proxy object, the data source object is returned to the resource pool. Any data source object that is released by the consumer and not reused after a 60-second time-out is automatically released by the resource pool.

When the consumer releases the session object, the resource pool keeps it until the data source object has timed out. This is because transaction enlistment occurs at the session level and can be very expensive. By caching the session object, the resource pool ensures that multiple connections enlisted in the same transaction are not required to reenlist each time.

To maximize scalability and performance, OLE DB resource pooling implements multiple, homogeneous pools. That is, there is a separate pool of connected data source objects for each combination of connection information used. Because it is not necessary to compare multiple different types of connections within one pool, this makes it very fast to identify a matching data source object. Because the pool is locked until a match is found, implementing these separate pools also reduces contention, which is extremely important in a scalable environment. (For more information about contention, see Writing Scalable OLE DB Providers.)

To further reduce contention, especially on a multiprocessor machine, OLE DB resource pooling maintains up to n+1 pools for each combination of connection information used, where n is the number of processors.

For the same reason, OLE DB services cache provider information, such as initialization properties, default registry information, and the provider's class factory. Registry lookups can be expensive, and retrieving property information requires task memory allocations. Caching provider information reduces the need for registry lookups.

Within a Component Services (or MTS, if you are using Windows NT) environment, OLE DB services automatically determine whether or not the calling thread is in a distributed transaction and if so, enlist the connected data source object in the transaction by calling methods on the provider's ITransactionJoin interface.


In ADO, OLE DB services are enabled by default.

Controlling Timeout Behaviors

Registry entries can be used to control session pooling timeout behavior. When set under a provider's CLSID entry in the registry, the SPTimeout value controls the length of time, in seconds, that unused sessions are held in the pool. SPTimeout should be entered as a DWORD value under HKEY_CLASSES_ROOT\CLSID\{class id} where {class id} is the CLSID of the OLE DB provider. The default value is 60 seconds.

The Retry Wait value controls the length of time, in seconds, to wait between connection attempts. It is entered as a DWORD value under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DataAccess\Session Pooling. The default value is 60 seconds.

For more information, see the following Knowledge Base articles: