Question

Setup:

I’m creating a .NET WinForms application in C# to allow our technical support folks to easily perform common tasks against our product’s SQL Server 2005 database. The application is using ADO.NET (SqlConnection) to connect to the database. One concern in developing this application was to minimize the overhead of connecting/re-connecting to the database each time a task (query) is initiated. The primary reason for this overhead, from my understanding, is due to the database having the AutoClose property set to “True”. I’d love to change this but unfortunately it isn’t under my control. I am also aware that creating a database connection involves some overhead regardless. I had a working implementation of the application that maintained a single connection (unless it was somehow closed before) through the lifecycle of the application. I then stumbled across an MSDN article on connection pooling in ADO.NET.

After reading the article (and other questions/answers here, here and here) it appears that the ADO.NET connection pool will maintain the connection to the database even if my application has properly disposed of its SqlConnection object. The connection will be retained in the pool and is re-usable until it has been idle for a certain time period or is otherwise broken. Thus my work to maintain a single connection in the application seems unnecessary and certainly more dangerous than simply creating/disposing of a SqlConnection each time it is needed.

Questions:

1. What implications are present when using ADO.NET Connection Pooling with an SQL Server database with “AutoClose” set to “true”?

2. I realize I may be oversimplifying when I describe how I believe Connection Pooling works behind the scenes but that aside, is my understanding accurate? If not, where does it need correction?

Answer 1

First question, why are the databases set to Auto Close? Valid scenarios include multi-tenant hosting and Express instances, but othar than that your databases should not be set to auto close.

Connection pooling will maintain a session opened on the SQL Server instance. A session is going to keep a reference on the current database, thus preventing its auto-closure. If your scenario involves one single application database, then the said database should not be on auto-close (is not the multi-tenant, thousands of databases, scenario). If your scenario involves thousands of databases, then your application should not keep them open, and besides it cannot keep them all open.

I think that the proper action in your case is to set the database to auto-close OFF.