Connection pooling is the term for the management of the connections of users making queries of databases. Though many users may not notice it, when there are a large number of users seeking access to an application server upon which a database resides, the sheer volume of connections may become nearly impossible for a server to maintain good connection with all of the connections at these times. Software engineering that enables connection pooling makes it possible for a server to manage connections well regardless of the high volume of connections making queries and enables response to these queries with sub-second speeds.
Connections must be of identical configuration to be included in a connection pool, so most server connection pooling programs have different connection pools running simultaneously. When a user seeks to connect, he or she is assigned to a pool with like configurations, if space is available. If there is not space available, the request is queued to be assigned as soon as one comes available. A user may not be aware that he or she is in a queue, but may simply notice that the database seems slow in query response; however, in the back office of database management systems, there is scanning of the pools to find space for the user to find an open connection. Most connection pooling programs have a set list of maximum users per pool and minimum amounts of time settings for which a connection can remain inactive before the connection is dropped and the availability is returned to the pool.
On the creation of a connection pool, a certain number of connection objects are created and added to the pool. For a pool to be considered active, it needs a minimum of number of objects. These connection objects are the availability seats that bond a connection to the pool, and they can be created and added to the pool as needed up to the maximum allowable within a pool. As users are satisfied with their querying and drop off their connection object, the objects are returned to the pool by the connection-pooling programs for use by another user or the same user when he or she returns.
One factor that may slow down response times in connection pooling is what is called pool fragmentation. Pool fragmentation usually occurs due to integrated security or too many databases residing on an existing set of servers. A database management system authenticating users and then queuing or assigning them to existing connection pool objects drains memory, and a tighter system design for accesses often clears up the too-many-databases problem. The integrated security system design of Windows-based programs in many connection-pooling programs demands that only one Windows-based user reside within a pool at a time. This can be cleared up by creation of more pools to accommodate additional requests needing to be answered concurrently.
If the connection-pooling program detects a user has been idle beyond a set period of time or the connection has become severed, it will return the connection object to the pool as an invalid object. If a server goes down while a connection is in effect, the connection can still be withdrawn even though the connection pool is not aware of the severed connection. ActiveX connection-pool programs usually then proceed to clear the pool of these connections as the server is restarted.