How important is it for me to pool my connections?

Question

It has been suggested to me that I rearrange my code to "pool" my ADO connections. On each web page I would open one connection and keep using the same open connection. But someone else told me that was important 10 years ago but is not so important now. If I make, let's say, 5 db calls on a web posting, is it problematic to be using 5 separate connections that I open/close?

Answer 1

I would say that it's a good idea to pool connections to anything. Almost everything has a finite connection limit. Additionally, there's an overhead associated with opening connections so using the same connection is much more efficient and saves response time.

What if you scale to 15 database calls? Those connections start piling up.

Pool 'em. There isn't a reason not to.

Sure, servers can chew through about anything these days but any response time you can save improves the user's experience.

Answer 2

The key thing I've found is how long it takes to create a database connection.

For an MSSQL Server on a slow connection halfway round the world, pooling will improve your app's responsiveness noticeably.

For a local MySQL install, you might not see a significant difference.

Answer 3

If you are using ADO.NET with SQL Server, then your connections are likely already pooled. Connection pooling is a very common practice with databases these days, and most of the time you use pooling without knowing it. My guess is that you were told that manually pooling connections is not that important, as it is generally automatic now.

It is a good practice, for a couple reasons. For one, creating a connection requires a certain amount of time, and constantly closing and opening your connections can waste valuable time. Second, connections are often a finite resource, and they should not be wasted. Often, stack-level limitations can also prevent how frequently connections can be opened. In high-throughput environments, actually opening and closing connections can use up a finite resource and create a bottleneck as they slowly become available again.

Answer 4

ADO.NET will often pool your connections anyway. This is sometimes considered to be a good thing; it tries hard to do the right thing and probably won't cause any grief.

You do not need to do anything special to achieve this, except create connections with the same parameters each time (this is not difficult, just use the same routine to create connections on each page).

Of course pooled connections can lead to difficulties in unusual cases, in which case you might want to disable them. But otherwise, just leave it well alone and it should work.

Answer 5

From framework 2.0 ASP.NET pools the connections to SQL Server by default.

However, what the people that you have talked to is talking about is not exactly pooling. Rather it's about reducing the number of database sessions.

As the connections are pooled, the penalty for closing a connection object and opening another is quite small. What usually happens is that the database connection itself is returned to the connection pool, and when you create the next connection object it just re-establishes the database connection using the same connection that you just returned.

Still, as there is a request made to the database each time a connection is re-establihed, you should try to reduce the number of connection objects that you use if it's reasonably possible.

The page cycle makes it a bit difficult to keep a connection object open for all database operations, so what I usually do is to use one connection object for the regular fetching of data done in Page_Load, then another connection if it's needed for example in a button event to update data in the database.

Answer 6

Connections to SQL Server are pooled in an ASP.NET application automatically: one pool for each distinct connection string. If you follow best practices and hide your database code away in a DAL whose connection string is constant throughout the application, then you'll always be working with a single pool of connection objects.

So what does this mean for your approach to the database? Well, for one it means that "closing a connection" really translates into "returning a connection to the pool" rather than truly closing the application's link to SQL Server. Thus, closing and reopening is not that big of a deal. However, with that being said, there are a few best practices to follow here.

First, you don't want to run out of connections in your pool even if your app scales up dramatically. That is, never think in turns of "the user on this page" - think in terms "the thousand people using this page".

Second, even though it isn't that taxing to close and reopen a connection, you'll generally want to open a connection as late as possible, use it until it is done and then close it as early as possible. The only exception is if you have a time-consuming process that must come after retrieving some data and before saving or retrieving other data.

Third, I would strongly advise against opening a connection early in the page lifecycle and closing it late in the lifecycle in a different method. Why? Because the worst thing you can do is to leave a connection open because you forget to add the logic to close it. Yes, they'll eventually be closed when the GC kicks in, but, again, if you are thinking about "the thousand people using this page* the chance for real trouble becomes obvious.

Now, what if you say that you are sure you close the connection because you always do so in some key, logical spot (e.g. the Page_Unload method). Well, this is great as long as you can confidently say you'll never throw an error that hops out of the page lifecycle. Which you can't. So...don't open in one method of the page lifecycle and close in another.

Finally, I would strongly recommend implementing a DAL that manages the database connections and provides tools for working with data. On top of that, build a Business Logic Layer (BLL) that uses these tools to supply type-safe objects to your UI (e.g. "Model" objects). If you implement the BLL objects with an IDisposable interface, then you can always ensure Connection safety using scope. It will also let you keep the database connection open for a very short period of time: just open the BLL object, pull data into a local object or list, and then close the BLL object (go out of scope). You can then work with the data returned by the BLL after the connection has been closed.

So...what does this look like. Well, on your Pages (the UI) you'll use Business Logic classes like this:

using (BusinessLogicSubClass bLogic = new BusinessLogicSubClass())
{
   // Retrieve and display data or pull from your UI and update
   // using methods built into the bLogic object
    .
    .
    .
}  // <-- Going out of scope will automatically call the dispose method and close the database connection.

Your BusinessLogicSubClass will be derived from a BusinessLogic object that implements IDisposable. It will instantiate your DAL class and open a connection like so:

public class BusinessLogic : IDisposable
{
    protected DBManagementClass qry;
    public BusinessLogic()
    {
        qry = new DBManagementClass();
    }

    public void Dispose()
    {
        qry.Dispose();  <-- qry does the connection management as described below.
    }

    ... other methods that work with the qry class to 
    ... retrieve, manipulate, update, etc. the data 
    ... Example: returning a List<ModelClass> to the UI ...

 }

when the BusinessLogic class goes out of scope, the Dispose method will automatically be called because it implements the IDisposable interface.

Your DAL class will have matching methods:

public class DBManagementClass : IDisposable
{
    public static string ConnectionString { get; set; }  // ConnectionString is initialized when the App starts up.

    public DBManagementClass()
    {
        conn = new SqlConnection(ConnectionString);  
        conn.Open();
    }

    public void Dispose()
    {
        conn.Close();
    }

    ... other methods
}

Given what I've described so far, the DAL doesn't have to be IDisposable. However, I use my DAL class extensively in my testing code when I'm testing new BLL methods so I constructed the DAL as an IDisposable so I could use the "using" construct during testing.

Follow this approach and, in essence, you'll never have to think about connection pooling again.