Sql connection in a windows service

Question

I have written a Windows Service which listens for data from a third party service, holds it in memory for a short time and periodically all the new data is flushed to the database.

I was initially opening a new connection each time I needed to flush the data and closing it again afterwards. (Every 5 seconds or so)

As the server seems to be getting hammered I have changed that so there is a single connection opened and reused for the life of the application.

Just wondering if this is a bad idea?

I usually do web stuff where the connection is open and closed over the life of a single request. What is the best practice for a windows service that needs to do the sort of operation I have described?

I was going to make a fault tolerant connection like this:

private SqlConnection _sqlConnection;
public SqlConnection SqlConnection
{
    get
    {
        if (_sqlConnection == null || !_sqlConnection.State.Equals(ConnectionState.Open))
        {
            var conn = new SqlConnection(_connectionString);
            conn.Open();
            return conn;
        }

        return _sqlConnection;
    }
}

so if some reason the existing connection is closed or faulted in some way we would get a new open one

is that bad design for any reason?

Answer 1

Call me conservative but I still think that leaving it up to the connection pool to manage the physical connections to the database is a better choice. So just open and close the connection normally, and leave to the pool to decide what to do. I've done that in web services without any problems, and you will have more connections available to handle the load.

Answer 2

Use common sense. If you are the single user of the database, hold onto the connection. If not you can really rely on connection pooling to do that for you.

I personally would go for opening the connection everytime. In .NET 2.0 a new feature was implemented so that if you have an open connection to a sql server and sql server gets restarted, etc... your connection becomes invalid and that is not something I can risk my service with. See my pos t from some years ago.

Answer 3

I would not try to maintain an open connection. There will be lots of edge cases where the connection will be become unusable and your code for managing the connection and making sure the old duff connection is correctly disposed would have to be absolutely bullet-proof.

I recommend the more common connection use pattern of open, use, close/dispose. The code will be much easier to write and maintain. Be absolutely sure you are disposing of all command and connection objects once you're done with them. Monitor your app with a profiling tool, and keep a check on the number of open database connections at the server to make sure your code is working the way you intended.

How often you need to dump the data into the database (and therefore open/use/close database connections) depends on a number of factors such as how much data will be in-memory before being dumped, the capability of the database server to consume the data, and the risk of losing data if you've accepted it from the web service, but haven't written it to the database and your service or the server crashes.

If your data is precious, you might want to consider having two processes. One process calls the web service and stores the received data securely in a message queue. Another process reads the messages from the queue and puts the data in the message in the database.

This way of handling this process means you can receive data whilst the database is temporarily down, and all the data will eventually be stored in the database.

Whilst this is a solid solution, it could just as easily be considered overkill, depending on your requirements.