|< BACK  NEXT >|
Consider the following scenario:
Assume that a component is set to open a connection to an SQL server database during activation. Let s say the component is being used over and over again, very quickly. Each time the component is used, a connection to the database is created. This is very inefficient; making a connection to a database can be very time consuming.
A better strategy would be to keep the connection alive and reuse it for the next invocation.
This is what a resource dispenser (RD) does.
A resource dispenser is a software component that manages the non-durable state of a resource, such as the connection to a database.
Do not confuse the resource manager with the resource dispenser, although both often work hand in hand:
An RM manages the durable state of the resource, such as the changes to a relational database. An RD manages the non-durable state of the resource, such as the connection to the database.
An RM is almost always implemented as an out-of-process server. An RD is always within the same process as that of the client.
Recall from Chapter 8 that, when a client connects to a resource manager, it gets a proxy to the resource manager (RM proxy). The RM proxy provides interfaces or APIs so that the client can talk to the resource manager.
An RM proxy is typically implemented as part of the Resource Dispenser.
Some commonly used examples of RDs are ODBC driver managers and OLE DB providers. Pooling offered by ODBC driver managers is called connection pooling. Pooling offered by OLE DB providers is called resource pooling.
An application can make its database connection by using an ODBC database driver either natively or by using ADO. The following code snippet uses ADO with ODBC to open a connection to an SQL server database AccountsDB.
Set aConn = CreateObject("ADODB.Connection") aConn.Open "DSN=LocalServer;database=AccountsDB;UID=sa;PWD=;"
When a client makes a database connection using ODBC, the ODBC driver manager keeps the connection in a pool and returns a copy to the client. When the client releases the connection, the ODBC driver manager does not drop the connection. Instead, it waits for a certain amount of time to see if the connection can be reused. When the next connection to the database is made, if the data source and the user information match the one in the pool, the request is satisfied from the connection in the pool. If there is no match, then a new connection is made to the database.
If the connection in the pool could not be used within the timeout period, the ODBC driver manager drops the connection.
To take advantage of ODBC connection pooling, the underlying ODBC driver must be thread-safe. Fortunately, the latest versions of the most popular ODBC drivers (SQL Server, Oracle, Access, etc.) are all thread-safe.
ODBC connection pooling can be enabled (or disabled) programmatically (as well as by other means such as manipulating the Windows registry). See the MSDN article, Pooling in the Microsoft Data Access Components, [Ahl-99] for details. For a COM+ application, connection pooling is automatically enabled. You do not have to explicitly enable it.
An application can also use OLE DB to create a data source object, either by invoking the data provider directly or by using ADO. The following code snippet uses ADO to create an OLE DB data source object to an SQL Server database AccountsDB:
Set aConn = CreateObject("ADODB.Connection") aConn.Open "Provider=SQLOLEDB;database=AccountsDB;UID=sa;PWD=;"
When the application creates an OLE DB data source object, the OLE DB services create a proxy data source object in the application s process. When the application attempts to create another data source object, the proxy tries to reuse the existing initialized data source to the database, if possible.
When the application releases the data source object, it is returned to the pool.
Notice the difference between ODBC connection pooling and OLE DB resource pooling. The former pools the ODBC connections to the database. The latter pools the OLE DB data source objects.
OLE DB resource pooling can be configured programmatically. The MSDN article, Pooling in the Microsoft Data Access Components, [Ahl99] provides an in-depth coverage on this topic.
|< BACK  NEXT >|