Why would moving our .NET /SQL Server website to a new host cause connection pool size to be exceeded?

Question

We've recently moved our company website to a new host. It is an ASP.NET site with C# code behind, connecting to MS SQL server.

Since moving the site to the new server, the site is exceeding the connection pool limit (which is not set explicitly, so I believe is at the default size of 100). Inspection of the open processes via SQL Server Management Studiorevealed that every database call appeared to be left open, and indeed, in the code I can find no explicitly closed connections at all.

The database connections are made in the following way:

DSLibrary.DataProviders.SqlProvider db = new DSLibrary.DataProviders.SqlProvider(Defaults.ConnStr);

There is precious little documentation about this DSLibrary and I assume that it's a library written by the original developer of the website. None of the class members of DSLibrary appear to explicitly close the connections either - nor are they defined within a using block to automatically close the connection.

My question is 2 fold.

1. How would we have not encountered this problem when the site was on a different host for nearly 3 years? Is there away to automatically close unused connections that I have not implemented on the SQL server?
2. Will I be best off rewriting every connection and procedure to explicitly open and close the connection database?

UPDATE The maximum number of concurrent connections property (Server Properties -> Connections tab) is set to 0.

If I run the website in debug mode on my development machine, connecting remotely to the production database, then the connections seem to close properly. This seems to show it's something to do with the way IIS is configured?

UPDATE 2 Setting the application pool to recycle after 30 worker processes has stopped the site exceeding maximum connections, but is now limiting some (session persistent) functionality - a recently visited items list resets very quickly and attempting to edit anything via the cms is impossible as you are logged out as soon as the processes recycle...

Answer 1

Most likely your code is leaking connections all over the place.

I'd bet money your old host had the app pool set to recycle pretty often, either from a memory usage or # requests processed point. The new host most likely has default cycling in place.

My recommendation is to first set the app pool to recycle a lot more often. Then fix the code. Either by refactoring out the DSLibrary (guessing that's home grown) or by simply changing it over to using clauses whereever you have database connections made.

update
One more thing, change your session properties to use sql server as the backing store that way you won't lose all the session information as the app recycles. This will buy you more time.

Answer 2

Have you checked the maximum number of concurrent connections property (Server Properties -> Connections tab)?

Answer 3

From what you say you don't appear to be wrapping the database in a using statement so you're leaking a connection each time. The system dumps the stuff when it gets around to it unless you explicitly dispose it--which is the purpose of using. You must always use a using (or otherwise ensure dispose is called) on anything that represents a resource outside your program. Files, database connections etc.