Connection pooling allows you to reuse connections rather than creating a new one every time the data provider needs to establish a connection to the underlying database. The DataDirect Connect
for ADO.NET data providers automatically enable connection pooling for your .NET client application.
The ClearPool and ClearAllPools methods of the Connection object remove all connections from a connection pool. ClearPool empties the connection pool associated with a specific connection. In contrast,
ClearAllPools empties all of the connection pools the data provider uses. Connections that are in use when the method is called are discarded when they are closed.
DataDirect Connect for ADO.NET data providers handle this situation transparently to the user. The application does not receive any errors on the Connection.Open() attempt because the data provider simply returns a connection from a connection pool. The first time the Connection object is used to execute a SQL statement (for example, through the Execute method on the Command object), the data provider detects that the physical connection to the server has been lost and attempts to reconnect to the server
before executing the SQL statement. If the data provider can reconnect to the server, the result of the SQL execution is returned to the application; no errors are returned to the application. The data provider uses the connection failover options, if enabled, when attempting this seamless reconnection. See
“Using Connection Failover” for information about configuring the data provider to connect to a backup server when the primary server is not available.
By default, the DataDirect Connect for ADO.NET data providers use a connection pool at all times. Each connection pool is defined by a unique connection string; changing the user in the connection string automatically creates a new connection pool. In an environment that uses OS authentication, users might all use the same connection string. However, they must have separate connection pools because their credentials are different.
Not all databases support reauthentication. For those databases that do, the user performing the switch must have been granted specific database permissions. Table 3-1 shows DataDirect Connect
for ADO.NET support for reauthentication and lists the required database permissions. Refer to your database documentation for information about granting permissions.
See “Authentication” for more information about using security with the DataDirect data providers.
See “Using Distributed Transactions” for more information about how the data providers process distributed transactions.
All DataDirect Connect for ADO.NET data providers include counters that let you debug and tune the connection performance of applications that use the data provider.