In a .NET Remoting server application should my database connection object be static

Question

I have a client Server app that uses .NET Remoting.
I have a helper class on the server portion of my app DBQuery.
DBQuery holds the DatabaseConnection, and the SQLCommand object, Commander and performs the queries passed to it.

Each time a query is performed, it verifies that the Commander has an open connection.
(it recreates the Commander if necessary.)

Considering it only connects to one Database, should I make my DBConnection static? (DBConnection creates the commander, DBConnection.CreateCommand())

current properties defined below:

/// <summary> connection used for querying with </summary>
public DBConn DBConnection 
{ get { return _conn ?? (_conn = new DBConn()); } }

/// <summary> Command object for processing the queries </summary>
private SqlCommand Commander
{
    get
    { 
      return _commander ??  
            (_commander = DBConnection.Connection.CreateCommand());
    }
}

DBConn - wraps SqlConnection and supplies the appropriate connection information from app.config

Answer 1

Even if it's static, never use a single connection - for one thing I don't believe the connection is thread-safe, so it won't necessarily take kindly to being called in parallel from two different clients.

Even if I'm wrong about that (and if I am, I still wouldn't share one connection between multiple threads), but if something happens with the database server, let's say it gets restarted or the service itself does (due to an upgrade released by your support team) then the connection will be dropped and you have no way of re-opening it again - your service/app has to be restarted. Chances are that it'll actually end up throwing an exception the next time you try and do something with it.

Also, where do you dispose the connection? It's very difficult to dispose of a static object unless you do the work to hook into a shutdown event, which isn't always reliable. Relying on an AppDomain's shutdown to dispose of things for you just isn't good practise.

Create a connection when you need it and dispose of it when you're done with it. Based on the code you've given, in simplest terms:

using(var conn = new DbConn().Connection)
{
  SqlCommand command = conn.CreateCommand();
  /* query and get results here */
}

Although in reality you might want to make you DbConn class IDisposable and chain to the underlying Connection's Dispose method in it's implementation of IDisposable.Dispose - that way you can do

using(var dbconn = new DbConn())
{
  //now you can use dbconn.Connection knowing that it will be disposed of
}

Note - the using block will still work if the new DbConn() is replaced with a factory method or property get - it just ensures that Dispose() is called on the object when then block exits, and even if an exception occurs.

By doing this, you get around all the problems I highlight in the first half of my answer.

Answer 2

The infrastructure is doing connection management (including pooling) behind the scenes so my recommendation is keep your code cleaner by not making it a static.