"Connection Pooling" is one the new features introduced in ODBC 3.0. Connection Pooling enables an ODBC application to reuse a connection from a pool of connections. Once a connection has been created and placed in the pool, an ODBC application can reuse the same driver and the connection within the same shared environment without performing the complete connection process (SQL Login) again.

Connection Pooling cuts down on the amount of time users must wait to establish a connection to the database since there is significant "ODBC overhead" with the call "SQL Login" and one should try to do as much work as possible on one login before closing the SQL connection.

Connection Pooling is supported by many SQL Database servers including IBM DB2, Microsoft SQL Server, Oracle, MySQL, and PostgreSQL. Connection Pooling is not supported by 4D Server.

To support Connection Pooling, an ODBC Driver that is "thread-safe" is required. What is "thread-safe?" For multi-threaded operating systems, ODBC 3.0 requires drivers that are thread-safe. The ODBC driver must ensure multiple threads can safely share the same ODBC handle. The 4D ODBC driver is not "thread-safe."

Instead of Connection Pooling, 4D instead uses "thread pooling." It is an internal mechanism to reuse system threads instead of creating and deleting them for each connection. The feature is completely transparent and is always automatically enabled and cuts down on some of the overhead associated with SQL Login.

Thread pooling is more generic, but the idea is the same - reuse resources that are costly to create and destroy. ODBC "overhead" in 4D is not negligible but is comparable to lots of other ODBC drivers. Generally, ODBC drivers are known to be 25% slower (or often even more!) in comparison with native connectors.