The connection pool is maintained by the Driver Manager. 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 size of the pool grows dynamically, based on the requested resource allocations. The size shrinks based on the inactivity time-out (the time since it was last used in a connection). The size of the pool is limited only by memory constraints and limits on the server.
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.
On Windows, to prevent unwanted repeated attempts by the Driver Manager to reestablish a connection when connection pooling is enabled, you can set ODBCGetTryWaitValue to save the information in the registry at the following location:
HKEY_LOCAL_MACHINE\Software\Odbc\Odbcinst.ini\ODBC Connection Pooling\RetryWait
If the Driver Manager encounters a bad connection in the pool, which was earlier connected successfully and returned to the pool, it attempts to reconnect it. If the connection still fails, the ODBC Driver Manager returns the error and marks the connection with the time. From that point until the RetryWait value expires, the ODBC Driver Manager returns a failure without testing the connection.
The number of connections enabled is dependent on the number of PEs (Parser Engines) on the Teradata Server. Each PE can have only 120 Teradata sessions. It is preferred to use a multi-node system for connection pooling rather than a single-node system due to performance problems.