“Abrir / fechar” SqlConnection ou manter aberto?

Tenho minha lógica de negócios implementada em classes estáticas simples com métodos estáticos. Cada um desses métodos abre / fecha a conexão SQL quando chamado:

public static void DoSomething(string something)
{
    using (SqlConnection connection = new SqlConnection("..."))
    {
        connection.Open();

        // ...

        connection.Close();
    }
}

Mas acho que evitar abrir e fechar uma conexão economiza desempenho . Eu fiz alguns testes loooongo tempo atrás com a classe OleDbConnection (não tenho certeza sobre SqlConnection) e definitivamente ajudou a trabalhar assim (pelo que me lembro):

//pass the connection object into the method
public static void DoSomething(string something, SqlConnection connection)
{
    bool openConn = (connection.State == ConnectionState.Open);
    if (!openConn)
    {
        connection.Open();
    }

    // ....

    if (openConn) 
    {
        connection.Close();
    }
}

Portanto, a questão é - devo escolher o método (a) ou método (b)? Eu li em outra questão de stackoverflow que o pool de conexão salvou o desempenho para mim, eu não tenho que me preocupar ...

PS. É um aplicativo ASP.NET - as conexões existem apenas durante uma solicitação da web. Não é um aplicativo ou serviço win.

Atenha-se à opção a .

O pool de conexão é seu amigo.

Use o Método (a), todas as vezes. Quando você começa a dimensionar seu aplicativo, a lógica que lida com o estado se tornará uma verdadeira dor se você não fizer isso.

O pool de conexão faz o que diz na lata. Basta pensar no que acontece quando o aplicativo é dimensionado e como seria difícil gerenciar manualmente o estado de abertura / fechamento da conexão. O pool de conexão faz um bom trabalho em lidar com isso automaticamente. Se você está preocupado com o desempenho, pense em algum tipo de mecanismo de cache de memória para que nada seja bloqueado.

Sempre feche as conexões assim que terminar de usá-las, para que a conexão de banco de dados subjacente possa voltar para o pool e ficar disponível para outros chamadores. O pool de conexão é muito bem otimizado, portanto, não há nenhuma penalidade perceptível para fazer isso. O conselho é basicamente o mesmo que para as transações - mantenha-as curtas e feche quando terminar.

Fica mais complicado se você tiver problemas de MSDTC usando uma única transação em torno do código que usa várias conexões; nesse caso, você realmente precisa compartilhar o objeto de conexão e apenas fechá-lo quando a transação for concluída.

No entanto, você está fazendo as coisas manualmente aqui, então você pode querer investigar ferramentas que gerenciam conexões para você, como DataSets, Linq to SQL, Entity Framework ou NHibernate.

Isenção de responsabilidade: eu sei que isso é antigo, mas encontrei uma maneira fácil de demonstrar esse fato, então estou investindo meus dois centavos.

Se você está tendo problemas para acreditar que o pooling será realmente mais rápido, tente:

Adicione o seguinte em algum lugar:

using System.Diagnostics;
public static class TestExtensions
{
    public static void TimedOpen(this SqlConnection conn)
    {
        Stopwatch sw = Stopwatch.StartNew();
        conn.Open();
        Console.WriteLine(sw.Elapsed);
    }
}

Agora substitua todas as chamadas para Open()com TimedOpen()e executar o seu programa. Agora, para cada string de conexão distinta que você tiver, a janela do console (saída) terá uma única longa aberta e várias aberturas muito rápidas.

Se você quiser rotulá-los, poderá adicionar new StackTrace(true).GetFrame(1) +à chamada para WriteLine.

Existem distinções entre conexões físicas e lógicas. DbConnection é um tipo de conexão lógica e usa uma conexão física subjacente ao Oracle. Fechar / abrir DbConnection não afeta seu desempenho, mas torna seu código limpo e estável - vazamentos de conexão são impossíveis neste caso.

Além disso, você deve se lembrar dos casos em que há limitações para conexões paralelas no servidor db - levando isso em consideração, é necessário fazer conexões muito curtas.

O conjunto de conexões libera você da verificação do estado da conexão - basta abri-los, usá-los e fechá-los imediatamente.

Normalmente você deve manter uma conexão para cada transação (sem cálculos paralelos)

por exemplo, quando o usuário executa a ação de cobrança, seu aplicativo precisa encontrar o saldo do usuário primeiro e atualizá-lo, eles devem usar a mesma conexão.

Mesmo se ado.net tiver seu pool de conexão, o custo de envio de conexão é muito baixo, mas reutilizar a conexão é a melhor escolha.

Por que não manter apenas uma conexão no aplicativo

Como a conexão está bloqueando quando você executa alguma consulta ou comando, isso significa que seu aplicativo está fazendo apenas uma operação de banco de dados por vez, o desempenho é ruim.

Mais um problema é que seu aplicativo sempre terá uma conexão, mesmo que seu usuário esteja apenas abrindo-o, mas sem operações. Se houver muitos usuários abrindo seu aplicativo, o servidor db irá custar toda a sua fonte de conexão em breve, enquanto seus usuários não o fizeram qualquer coisa.