brant interactive

And has been temporarily closed.

After re-writing an existing asp.net app and migrating from 1.1 to 2.0 I was getting the connection pooling error:

System.Web.HttpUnhandledException: Exception of type ‘System.Web.HttpUnhandledException’ was thrown. —> System.InvalidOperationException: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.

While familiar with the basics, I spent a lot of time reading all about connection pooling (fun stuff, eh?), to see if I can find anything new that might give me some insight into what’s going on. Without going into too much detail about connection pooling itself, the bottom line is that you need to be sure any time a connection is opened and made to your database that the connection is closed. I’m certain they are all closed as the data access relies on the first version of the DAAB, which handles the opening and closing of the connections. What’s worse, I’m supposedly in my own application pool, which makes pointing the finger at some other moron harder to do:) .

I did find a place in the app where in theory more than the default 100 connections could get opened, but it still shouldn’t result in any connections being left open. It occurs in a datagrid where I use the OnItemDataBound event to create an object for each row in order to get at a property of the object needed for the row data. I know, probably better ways to do it, but it still shouldn’t result in the connection pooling error. If the DAAB handles the open and closing all should be well. That is the place though, where I seem to have pin pointed the trouble. When I go from viewing 10 rows to 100, the pooling error always occurs. If for some reason, upon the creation of each object the connection wasn’t being closed, the error could happen.

At this point, having gone partially insane, and as a temporary option, what I did was use a different connection string wrapped in a try/catch block that has this attribute, “Pooling=false;”. If the first attempt fails, it falls back on this one, which does not use connection pooling. There is a performance hit, but for this app, it’s not a huge deal because it’s inside an admin section. Oh, and not to point the blame elsewhere, but I am able to run the same code on another machine without error. That’s not to say it’s the hosts config that’s somehow to blame for sure, but it does make matters more confusing for sure.