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?¿Debo persistir una sqlconnection en mi capa de acceso a datos?
¿Qué has hecho? ¿Qué funcionó bien y qué funcionó mal?
En la mayoría de los casos, la agrupación de conexiones .NET maneja esto para usted. A pesar de que estás abriendo y cerrando conexiones por 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á utilizando SQL Server: http://msdn.microsoft.com/en-us/library/8xx3tyca.aspx
OLE DB, ODBC, Oracle: http://msdn.microsoft.com/en-us/library/ms254502.aspx
Dino Esposito artículo: http://www.wintellect.com/Articles/ADO%20NET%20Connection.pdf
Puede anular el comportamiento por defecto con la puesta en común connectionstring nombre/valores: http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring.aspx. Vea la segunda tabla de configuraciones que contiene 'Connection Lifetime'.
Interesante, no lo sabía. – VVS
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.
No hay demasiada sobrecarga ya que, por configuración 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.
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 a veces es difícil hacer un seguimiento y depurarlo, si desconectas un DataReader de la conexión 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.
Esto generalmente no es una buena cosa (puede causar una fuga y eventualmente quedarse sin conexiones), pero confíe en el Pool de conexión para el rendimiento y abra las conexiones según sea necesario y cierre las conexiones lo más rápido posible.
Bill Vaughn tiene una serie de artículos útiles acerca de la agrupación de conexiones y el acceso a los datos incluidos this one
Durante años hemos tenido el cliente a mantener una única conexión persistente a 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 utilizarla (es decir, emitir un select arrojará un 'Error General de SQL')
Ahora usamos una clase estática disponible en todo el mundo cuyo trabajo es entregarle un conexión nueva a la base de datos, y cuando haya terminado 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);
}
Nos hacemos esto porque no hay inicialización necesario para cuando que conectarse a la base de datos (que almacenamos información es CONTEXT_INFO de SQL Server, y hay que vaciar esa información cuando desconectamos)
Al hacer conexiones en el tiempo de espera de la piscina? –
Puede controlarlo a través de los nombres/valores de la conexión: http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring.aspx. Desplácese hacia abajo hasta la segunda tabla que contiene 'Duración de la conexión'. –