.net - persistencia - ¿Debería persistir una sqlconnection en mi capa de acceso a datos?

orm c#

Question

Parece que hay una gran cantidad de gastos generales involucrados en abrir y cerrar rápidamente sqlconnections. ¿Debo persistir en una conexión (una, por cliente, por base de datos) o continuar declarando un nuevo objeto sqlconnection cada vez que lo necesito, y asegurarme de que me ocupo de limpiarlo?

¿Qué has hecho? ¿Qué funcionó bien y qué funcionó mal?

Answer 1

Durante años, el cliente mantuvo una única conexión permanente con la base de datos. El problema es detectar una falla de conexión intermitente y reconectar con gracia. Muy a menudo no sabrá que una conexión falló hasta que intente usarla (es decir, al emitir una selección arrojará un ''Error General de SQL'')

Ahora usamos una clase estática disponible en todo el mundo cuyo trabajo es proporcionarle una nueva conexión a la base de datos, y cuando termine con ella, utiliza la misma clase para deshacerse de la conexión.

DbConnection conn = Database.GetConnection();
try
{
//do stuff with the connetion
...
}
finally
{
Database.DisposeConnection(conn);
}

Hacemos esto porque hay inicialización necesaria cuando nos conectamos a la base de datos (almacenamos información es CONTEXT_INFO de SQL Server, y debemos vaciar esa información cuando nos desconectamos)

Answer 2

En la mayoría de los casos, la agrupación de conexiones .NET maneja esto por usted. A pesar de que estás abriendo y cerrando conexiones a través del código, eso no es lo que está sucediendo detrás de escena. Cuando crea una instancia y abre una conexión, .NET busca una conexión existente en el grupo de conexiones con la misma conexión y, en su lugar, le proporciona esa conexión. Cuando cierra la conexión, vuelve al grupo de conexiones para usarla en el futuro.

Si está usando SQL Server: http://msdn.microsoft.com/en-us/library/8xx3tyca.aspx

OLE DB, ODBC, Oracle: http://msdn.microsoft.com/en-us/library/ms254502.aspx

Artículo de Dino Esposito: http://www.wintellect.com/Articles/ADO%20NET%20Connection.pdf

Puede anular el comportamiento de agrupamiento predeterminado con los valores / nombre de la conexión: http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring.aspx . Vea la segunda tabla de configuraciones que contiene ''Connection Lifetime''.

Answer 3

No hay demasiados gastos generales ya que, de forma predeterminada, las agrupaciones se almacenan en el grupo de conexiones. Por lo tanto, cuando abres una conexión, a menudo obtendrás una conexión lista desde el grupo. Crear SqlConnections no me ha dado ningún problema.

Answer 4

Por lo general, esto no es algo bueno (puede causar una fuga y, finalmente, quedarse sin conexiones), sino que confía en el conjunto de conexiones para obtener rendimiento y abre las conexiones según sea necesario y cierra las conexiones lo más rápido posible.

Bill Vaughn tiene una serie de artículos útiles sobre la agrupación de conexiones y el acceso a los datos, incluido este

Answer 5

Si está utilizando la misma cadena de conexión, sus conexiones se agruparán. Solo debe tener una conexión abierta todo el tiempo que la necesite.

Answer 6

Tuve el mismo pensamiento, así que usé la misma conexión en un circuito cerrado para evitar tener que crear una instancia de otro cuando lo necesitaba. Pero en algún momento es difícil hacer un seguimiento y depurarlo, si desconectas un DataReader y luego intentas hacer otro mientras el mismo lector aún está activo, obtendrás una excepción. Por lo tanto, solo lo recomendaría si es muy frecuente como un ciclo cerrado, de lo contrario no vale la pena.