

To use a connection pool, an application performs the following steps:Įnables connection pooling by calling SQLSetEnvAttr to set the SQL_ATTR_CONNECTION_POOLING environment attribute to SQL_CP_ONE_PER_DRIVER or SQL_CP_ONE_PER_HENV.
#Odbc manager locatio driver
Eventually the Driver Manager might make a new connection, assuming the pool is empty. New connection requests might not find a usable connection in the pool. If a connection has been lost (reported via SQL_ATTR_CONNECTION_DEAD), the ODBC Driver Manager will destroy that connection by calling SQLDisconnect in the driver. The connection is dead if the last trip to the server failed, and not dead if the last trip succeeded.

Instead, a driver should just return the last known state of the connection. Specifically, a call to get this connection attribute should not cause a round trip to the server. (Drivers conforming to earlier versions of ODBC can also support this attribute.)Ī driver must implement this option efficiently or it will impair the connection pooling performance. The value SQL_CD_TRUE means that the connection has been lost, while the value SQL_CD_FALSE means that the connection is still active. This is a read-only connection attribute that returns either SQL_CD_TRUE or SQL_CD_FALSE. A new connection attribute has been defined in ODBC 3*.x*: SQL_ATTR_CONNECTION_DEAD. Otherwise, the Driver Manager keeps on handing out the dead connection to the application whenever a transient network failure occurs. When the Driver Manager is pooling connections, it needs to be able to determine if a connection is still working before handing out the connection.

The Driver Manager determines whether a specific connection in a pool should be used according to the arguments passed in SQLConnect or SQLDriverConnect, and according to the connection attributes set after the connection was allocated. The size of the pool is limited only by memory constraints and limits on the server. It shrinks based on the inactivity timeout: If a connection is inactive for a period of time (it has not been used in a connection), it is removed from the pool. The size of the pool grows dynamically, based on the requested resource allocations. Connections are drawn from the pool when the application calls SQLConnect or SQLDriverConnect and are returned to the pool when the application calls SQLDisconnect. The connection pool is maintained by the Driver Manager. This means the driver is able to handle a call on any thread at any time and is able to connect on one thread, to use the connection on another thread, and to disconnect on a third thread. When using connection pooling, the application must not execute SQL statements that change the database or the context of the database, such as changing the, which changes the catalog used by a data source.Īn ODBC driver must be fully thread-safe, and connections must not have thread affinity to support connection pooling. x behavior, as long as the application can call SQLSetEnvAttr. A connection in a connection pool can be used repeatedly by multiple components.Ĭonnection pooling can be used by an ODBC application exhibiting ODBC 2. This means that stand-alone components in the same process can interact with each other without being aware of each other. In addition to performance gains, the connection pooling architecture enables an environment and its associated connections to be used by multiple components in a single process. This can be particularly significant for middle-tier applications that connect over a network or for applications that repeatedly connect and disconnect, such as Internet applications. Using a pooled connection can result in significant performance gains, because applications can save the overhead involved in making a connection. Once a connection has been created and placed in a pool, an application can reuse that connection without performing the complete connection process. Connection pooling enables an application to use a connection from a pool of connections that do not need to be re-established for each use.
