“Abrir / cerrar” SqlConnection o mantener abierto?

Tengo mi lógica de negocio implementada en clases estáticas simples con métodos estáticos. Cada uno de estos métodos abre / cierra la conexión SQL cuando se le llama:

public static void AddSomething(string something) { using (SqlConnection connection = new SqlConnection("...")) { connection.Open(); // ... connection.Close(); } } 

Pero creo que evitar abrir y cerrar una conexión ahorra rendimiento . Hice algunas pruebas hace mucho tiempo con la clase OleDbConnection (no estoy seguro acerca de SqlConnection), y definitivamente ayudó a trabajar así (por lo que recuerdo):

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

Entonces la pregunta es: ¿debería elegir el método (a) o el método (b)? Leí en otra pregunta de stackoverflow que la conexión del rendimiento guardado de la agrupación para mí, no tengo que molestar en absoluto …

PD. Es una aplicación ASP.NET: las conexiones existen solo durante una solicitud web. No es una aplicación o servicio win.

Mantente en la opción a .

El grupo de conexión es tu amigo.

Use el método (a), cada vez. Cuando comiences a escalar tu aplicación, la lógica que trata con el estado se convertirá en un verdadero dolor si no lo haces.

La agrupación de conexiones hace lo que dice en la lata. Solo piense en lo que sucede cuando la aplicación escala, y qué tan difícil sería administrar manualmente el estado de apertura / cierre de la conexión. El grupo de conexiones hace un buen trabajo al manejar esto automáticamente. Si le preocupa el rendimiento, piense en algún tipo de mecanismo de memoria caché para que nada se bloquee.

Siempre cierre las conexiones tan pronto como haya terminado con ellas, para que la conexión de la base de datos subyacente pueda volver al grupo y esté disponible para otras personas que llaman. La agrupación de conexiones está bastante optimizada, por lo que no hay una penalización notable por hacerlo. El consejo es básicamente el mismo que para las transacciones: manténgalas cortas y cerradas cuando haya terminado.

Se vuelve más complicado si se encuentra con problemas de MSDTC al usar una única transacción en torno al código que usa múltiples conexiones, en cuyo caso usted realmente tiene que compartir el objeto de conexión y solo cerrarlo una vez que la transacción haya finalizado.

Sin embargo, está haciendo las cosas a mano aquí, por lo que es posible que desee investigar herramientas que administren conexiones para usted, como DataSets, Linq a SQL, Entity Framework o NHibernate.

Descargo de responsabilidad: Sé que esto es viejo, pero encontré una manera fácil de demostrar este hecho, por lo que estoy poniendo mi granito de los dos centavos.

Si tiene problemas para creer que la puesta en común realmente va a ser más rápida, intente esto:

Agregue lo siguiente en alguna 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); } } 

Ahora reemplace todas las llamadas a Open() con TimedOpen() y ejecute su progtwig. Ahora, para cada cadena de conexión distinta que tenga, la ventana de la consola (salida) tendrá una única ejecución larga abierta, y se abrirá un grupo de aperturas muy rápidas.

Si desea etiquetarlos, puede agregar new StackTrace(true).GetFrame(1) + a la llamada a WriteLine .

Hay distinciones entre conexiones físicas y lógicas. DbConnection es un tipo de conexión lógica y utiliza una conexión física subyacente a Oracle. Cerrar / abrir DbConnection no afecta su rendimiento, pero hace que su código esté limpio y estable; las fugas de conexión son imposibles en este caso.

También debe recordar acerca de los casos en que existen limitaciones para las conexiones en paralelo en el servidor db, teniendo esto en cuenta que es necesario hacer sus conexiones muy cortas.

El grupo de conexiones lo libera de la comprobación de estado de conexión; simplemente ábralo, úselo y ciérrelo inmediatamente.

Normalmente, debe mantener una conexión para cada transacción (no se calcula en paralelo)

por ejemplo, cuando el usuario ejecuta la acción de carga, su aplicación necesita buscar primero el saldo del usuario y actualizarlo, deben usar la misma conexión.

Incluso si ado.net tiene su grupo de conexiones, el costo de la conexión de despacho es muy bajo, pero la conexión de reutilización es una mejor opción.

¿Por qué no mantener solo una conexión en la aplicación?

Debido a que la conexión se bloquea cuando ejecuta alguna consulta o comando, eso significa que su aplicación solo está haciendo una operación de base de datos al mismo tiempo, que tan pobre es su rendimiento.

Un problema más es que su aplicación siempre tendrá una conexión aunque su usuario solo la abra pero no tenga operaciones. Si hay muchos usuarios abriendo su aplicación, el servidor db le costará todo su origen de conexión pronto, mientras que sus usuarios no lo hicieron. cualquier cosa.