Connection pools are stored within App Domain. For an IIS application, this will be within the app domain that is hosted within a specific w3wp.exe process (one per application pool). For a windows forms application, the connect pools are still stored at the App Domain level, within the process. A connection pool will be created per process/App Domain/executing user (in the case of integrated authentication)/connection string.
Per figure 1, you can see individual identical connections reside within connection pools, which in turn reside within a pool group. A pool group is merely a collection of connection pools that differ only by the executing user. Pool groups are in turn within an app domain within the executing process.
Since connection pools are hosted within an app domain, the lifetime of the connections is the same as the app domain.
SQL Server mirroring
To utilize SQL mirroring, add the “Failover Partner=[server name\instance name]” attribute to your connection string.
ADO.Net will manage determining that the principal server is the one named in the “Data Source” attribute initially.
If a connection pool has already been established within the current app domain when a failover to the mirrored server occurs, the following steps happen:
- A SqlException is raised with the message “A transport-level error has occurred when sending the request to the server….” Note: you must handle this raised exception, close the current connection and re-open the connection in order to handle the failover as smoothly as possible.
- Failover is detected by ADO.Net
- Failover partner is identified from connection string
- Pool groups are cleared
- New connection is created in a connection pool with a server name of the failover partner
