When modifying linq-to-sql commandtext, should the connection be closed?

I'm modifying the commandtext of linq-to-sql to force it to use nolock, like this...

if (db.Connection.State == System.Data.ConnectionState.Closed)
    db.Connection.Open();

var cmd = db.GetCommand(db.Customers.Where(p => p.ID == 1));

cmd.CommandText = cmd.CommandText.Replace("[Customers] AS [t0]", "[Customers] AS [t0] WITH (NOLOCK)");

var results = db.Translate(cmd.ExecuteReader());

It's an MVC application, so the datacontext is in the base controller, and may have been used before this code, and more importantly, after. Should I be closing the connection in this routine? Or not at all? Or only if I opened it here?

Update:

I'm now using the more general function (in the DataContext class) to modify the commandtext, and closing the connection if it was opened here. And the open has been moved down to the ExecuteReader. So far it has been working and reducing the sporadic deadlock issues. The results do not have to be right-up-to-the-second.

    public List<T> GetWithNolock<T>(IQueryable<T> query)
    {
        // to skip nolock, just...
        // return query.ToList();

        List<T> results = null;

        bool opened = false;

        try
        {
            if (Connection.State == System.Data.ConnectionState.Closed)
            {
                Connection.Open();

                opened = true;
            }

            using (var cmd = GetCommand(query))
            {
                cmd.CommandText = Regex.Replace(cmd.CommandText, @"((from|inner join) \[dbo.*as \[t\d+\])", "$1 with (nolock)", RegexOptions.IgnoreCase);

                results = Translate<T>(cmd.ExecuteReade开发者_开发技巧r()).ToList();
            }
        }
        finally
        {
            if (opened && Connection.State == System.Data.ConnectionState.Open)
            {
                Connection.Close();
            }
        }

        return results;
    }

I have found in the past that using a Transaction in the recommended way causes the site to run out of connections overnight. As far as I know, that's a bug in linq-to-sql. There may be ways around it, but I'm trying to keep my main code straightforward. I now "just" have to do this...

var users = GetWithNolock<User>(
  Users
  .Where(u => my query
);

If you Open it, you should Close it. Other LinqToSql operations match this pattern.

In my code, I unconditionally open the connection and close the connection in a finally. If someone passes me an open connection, that's their fault and I happen to close it for them.

You could delay opening the connection until just before ExecuteReader.