In terms of processing and Inter-Process Communication (IPC), it is quite expensive to create a connection to a data source. You can see this if you step through any code that creates an initial data source connection—there is a significant delay while the network channel is opened, handshaking with the server occurs, a connection to the SQL Server is made, and user credentials are authenticated. This process is true even with the most simple connection—more complex connections that include transactions or the attaching of database files take even longer.
Inside an application, it would be unusual to find that a different type of connection or data source location is required for each database operation. Perhaps, then, it would make sense if, instead of the connection being destroyed after each operation, it could be reused to save the expense of opening a new connection? Connection pooling performs this connection optimization.
If the connection string values match between connection requests and an existing connection exists in the connection pool, ADO.NET reuses the existing connection instead of creating a new connection. Different connection pools are created based upon differing connection string values, transactions, and Integrated Security identity. It is good practice— and strongly recommended—that you close the Connection object after each operation so it can be returned to the connection pool.
The good news is that connection pooling is enabled by default and in most cases does not require any configuration to suit your requirements
A persistent connection is one which, once opened, remains available for use until it is closed explicitly after performing all required database operations. To do this, connection pooling must be disabled. This is configured by setting Pooling=false in the connection string
From: ADO.Net MCTS Certification book



Use the Highlighter
This website now has an AutoPublish widget: