SqlConnection “apri / chiudi” o tieni aperto?

Ho implementato la mia logica aziendale in semplici classi statiche con metodi statici. Ciascuno di questi metodi apre / chiude la connessione SQL quando viene chiamato:

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

        // ...

        connection.Close();
    }
}

Ma penso che evitare di aprire e chiudere una connessione salvi le prestazioni . Ho fatto alcuni test molto tempo fa con la classe OleDbConnection (non sono sicuro di SqlConnection), e sicuramente ha aiutato a funzionare in questo modo (per quanto ricordo):

//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();
    }
}

Quindi la domanda è: devo scegliere il metodo (a) o il metodo (b)? Ho letto su un'altra domanda di stackoverflow che il pool di connessioni mi ha salvato le prestazioni, non devo preoccuparmi affatto ...

PS. È un'app ASP.NET: le connessioni esistono solo durante una richiesta web. Non una win-app o un servizio.

Attenersi all'opzione a .

Il pool di connessioni è tuo amico.

Usa il metodo (a), ogni volta. Quando inizi a ridimensionare la tua applicazione, la logica che si occupa dello stato diventerà un vero problema se non lo fai.

Il pool di connessioni fa quello che dice sulla latta. Basti pensare a cosa succede quando l'applicazione si ridimensiona e quanto sarebbe difficile gestire manualmente lo stato di apertura / chiusura della connessione. Il pool di connessioni fa un ottimo lavoro nel gestirlo automaticamente. Se sei preoccupato per le prestazioni, pensa a una sorta di meccanismo di cache di memoria in modo che nulla venga bloccato.

Chiudi sempre le connessioni non appena hai finito, in modo che la connessione al database sottostante possa tornare nel pool ed essere disponibile per altri chiamanti. Il pool di connessioni è abbastanza ben ottimizzato, quindi non ci sono penalità evidenti per farlo. Il consiglio è fondamentalmente lo stesso delle transazioni: mantienile brevi e chiudi quando hai finito.

Diventa più complicato se stai riscontrando problemi di MSDTC utilizzando una singola transazione attorno al codice che utilizza più connessioni, nel qual caso devi effettivamente condividere l'oggetto connessione e chiuderlo solo una volta completata la transazione.

Comunque tu stia facendo le cose a mano qui, quindi potresti voler indagare sugli strumenti che gestiscono le connessioni per te, come DataSet, Linq to SQL, Entity Framework o NHibernate.

Disclaimer: so che questo è vecchio, ma ho trovato un modo semplice per dimostrarlo, quindi sto mettendo i miei due centesimi.

Se hai difficoltà a credere che il raggruppamento sarà davvero più veloce, prova questo:

Aggiungi quanto segue da qualche parte:

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

Ora sostituisci tutte le chiamate a Open()con TimedOpen()ed esegui il tuo programma. Ora, per ogni stringa di connessione distinta che hai, la finestra della console (output) avrà un'unica apertura di lunga durata e un gruppo di aperture molto veloci.

Se desideri etichettarli, puoi aggiungerli new StackTrace(true).GetFrame(1) +alla chiamata a WriteLine.

Esistono distinzioni tra connessioni fisiche e logiche. DbConnection è un tipo di connessione logica e utilizza la connessione fisica sottostante a Oracle. La chiusura / apertura di DbConnection non influisce sulle prestazioni, ma rende il codice pulito e stabile: in questo caso le perdite di connessione sono impossibili.

Inoltre dovresti ricordare i casi in cui ci sono limitazioni per le connessioni parallele sul server db - tenendo conto di ciò è necessario rendere le tue connessioni molto brevi.

Il pool di connessioni ti libera dal controllo dello stato della connessione: aprili, usali e chiudili immediatamente.

Normalmente dovresti mantenere una connessione per ogni transazione (nessun calcolo parallelo)

Ad esempio, quando l'utente esegue un'azione di addebito, l'applicazione deve prima trovare il saldo dell'utente e aggiornarlo, dovrebbe utilizzare la stessa connessione.

Anche se ado.net ha il suo pool di connessioni, il costo della connessione di invio è molto basso, ma riutilizzare la connessione è una scelta migliore.

Perché non mantenere solo una connessione nell'applicazione

Poiché la connessione si blocca quando esegui una query o un comando, significa che la tua applicazione sta eseguendo solo un'operazione di database allo stesso tempo, per quanto siano scarse le prestazioni.

Un altro problema è che la tua applicazione avrà sempre una connessione anche se il tuo utente l'ha semplicemente aperta ma nessuna operazione.Se ci sono molti utenti che aprono la tua applicazione, il server db costerà presto tutta la sua fonte di connessione mentre i tuoi utenti non l'hanno fatto nulla.