.net - obtener - ocurrio un error durante la comunicacion con la fuente de datos
¿Es seguro mantener las conexiones de bases de datos abiertas durante mucho tiempo? (9)
Si bien los detalles específicos son importantes en general, no hay nada de malo en mantener las conexiones abiertas durante largos períodos de tiempo.
Si su aplicación es la agrupación de conexiones, las ranuras de conexión en el grupo generalmente permanecen conectadas hasta que se necesiten.
Fuera de los modelos de licencia basados en conexión que son extremadamente raros hoy en día el mantenimiento de las conexiones en sí consumen recursos insignificantes.
Los clientes SQLServer que operan a través de TCP envían keepalives a intervalos de 30 segundos. (Keepalives son esencialmente paquetes de 0 len TCP) usualmente se trata de tráfico neglegable.
Si está operando en entornos con muy poco ancho de banda o con enlaces WLAN poco confiables que aumentan los intervalos de mantenimiento TCP puede ayudar a aumentar las posibilidades de que las conexiones de larga duración permanezcan activas y reducir la cantidad de "conversaciones inactivas" en el cable.
Hay razones por las que desea o no desea usar grupos de conexiones.
Contra el uso de piscinas:
Elimina la posibilidad de contaminación ambiental, donde otras consultas establecen opciones de entorno especiales que pueden interferir con la ejecución de consultas (xact_abort, transaction isolation levels ..etc)
Si un límite de conexión configurado / con licencia está vigente, las conexiones inactivas en su aplicación son conexiones que no están disponibles para su uso por otras aplicaciones.
Contra la conexión cada vez:
La configuración de la conexión (especialmente la configuración de conexión segura) requiere una serie de viajes de ida y vuelta adicionales entre el cliente y el servidor: los viajes redondos tienden a ser un factor determinante del rendimiento para las aplicaciones WAN.
Tengo una aplicación de cliente .net que está conectada a una base de datos remota. ¿Es seguro mantener abierta una sola conexión durante toda la vida del cliente (horas)?
¿La respuesta es válida si tengo varios clientes (10 o 100) en funcionamiento?
Gracias
No debería mantener las conexiones abiertas así, en términos generales. .NET tiene un sistema de agrupación de conexiones ADO.NET que hace exactamente lo que estás tratando de hacer, y lo hace mucho mejor. ;-)
actualización: soy un ''tard'' publicado reactivamente no se aplica aquí.
-Oisin
Absolutamente es seguro hacer esto. Así es como funcionan las aplicaciones cliente-servidor. Si está utilizando una aplicación de tres niveles, el servidor de aplicaciones mantendrá un grupo de conexiones abiertas de todos modos.
La escalabilidad es un problema, o al menos solía ser en los días en que las máquinas tenían menos memoria que el kit moderno. Con una aplicación de dos niveles (cliente-servidor), cada cliente abrió una conexión y la mantuvo abierta. Esto tuvo varios efectos:
La memoria se usó por conexión, por lo que un gran número de conexiones (relativamente) inactivas consumiría la memoria de la máquina. Sin embargo, un servidor moderno de 64 bits puede tener decenas o cientos de GB de memoria, por lo que podría admitir una gran cantidad de tales conexiones.
Si una transacción se dejó sin confirmar en la máquina del cliente, los bloqueos se mantendrían abiertos mientras la transacción estuviera abierta. Esto dio lugar a una clase de problemas cuando alguien podía comenzar una transacción, ir a almorzar y olvidar que habían dejado algo abierto. Esto bloquearía los registros a los que hace referencia la transacción durante horas.
Las transacciones podrían, sin embargo, cubrir fácilmente múltiples accesos a la base de datos, lo cual es más difícil de hacer con un grupo de conexión.
Una arquitectura agrupada, que es común en las arquitecturas de 3 niveles, tiene un número finito de conexiones entre el servidor de aplicaciones y la base de datos. Las consultas simplemente usan la siguiente conexión disponible y las actualizaciones se confirman de inmediato. Esto utiliza menos recursos ya que solo tiene un número finito de conexiones abiertas y (junto con una estrategia de concurrencia optimista ) eliminará una gran cantidad de posibles problemas de concurrencia de aplicaciones.
Para usar transacciones largas (es decir, transacciones que cubren más de una llamada a la base de datos), uno tiene que desvincular la transacción de la conexión. Esta es la arquitectura básica de un monitor de TP y existen algunos protocolos estándar, tales como XA u OLE Transactions para admitir esto. Si este tipo de transacción gestionada externamente no está disponible, la aplicación debe construir una transacción compensatoria que deshaga los cambios realizados por la transacción de la aplicación. Este tipo de arquitectura a menudo es utilizada por sistemas de gestión de flujo de trabajo.
Depende de la base de datos y de lo que esté haciendo con ella. Hay un gasto por abrir y cerrar cualquier conexión en su mayor parte. Por ejemplo, si está utilizando SQLCE en un dispositivo móvil (SQL Server Compact Edition), en realidad es un enfoque recomendado para dejar la conexión abierta en el dispositivo, ya que el gasto de abrirlo y cerrarlo no justifica la molestia.
Ahora, por el contrario, si está trabajando con una base de datos multiusuario, querrá administrar esas conexiones con más cuidado. Como ya se mencionó, la agrupación de conexiones ADO.Net hace un buen trabajo al ayudarlo a administrar la eficiencia.
Es seguro. Eso es más o menos lo que hace la agrupación ... mantiene las conexiones abiertas durante la ejecución del programa y las utiliza para diferentes consultas.
Pero es posible que desee tener cuidado con los tiempos de espera de conexión de la base de datos. La conexión se quedará obsoleta y comenzarás a recibir errores extraños. Establezca el valor de tiempo de espera en la base de datos en un valor muy grande o mantenga activa la conexión con consultas ficticias ocasionales.
La dificultad con las conexiones de larga vida es que puede que no estés completamente seguro de que todavía estén allí. Una falla de red, un reinicio del servidor o un firewall con estado que olviden parte de su estado podrían dar como resultado una conexión "obsoleta" que parece abierta, pero luego se genera un error cuando intenta usarla.
Los esquemas de agrupación de conexiones normalmente resuelven esto haciendo que algún sistema verifique ocasionalmente que las conexiones en el grupo estén sanas, o que tengan un tiempo de espera luego de que las conexiones no utilizadas se descarten.
En términos generales, en un sistema distribuido debe codificar fallas de todo tipo, mantener las conexiones de larga duración abiertas hace que esto sea más difícil, pero si está contento de hacerlo, genial.
Por supuesto. Realmente solo tiene problemas cuando mantiene transacciones abiertas durante un período prolongado (en ciertos niveles de aislamiento).
Hay un límite de conexión con licencia, y las conexiones aceptan memoria en el servidor, por lo que cuanto menos, mejor.
Realmente depende de la cantidad de clientes que tenga con las conexiones abiertas y de si está utilizando la agrupación de conexiones de cualquier tipo.
Si usted es un sistema de tres niveles y su nivel medio tiene habilitada la agrupación de conexiones, entonces la configuración del cliente no es aplicable. Si no está utilizando un nivel intermedio, ahora sería el momento de considerarlo si le preocupa la cantidad de conexiones al servidor, ya que este nivel intermedio lo ayudará a administrarlo mucho mejor.
Cada conexión abierta consume una cierta cantidad de memoria en el servidor y agrega un poco de sobrecarga. Dado un sistema de dos niveles donde el cliente está hablando directamente con el servidor, entonces necesita ver las especificaciones del servidor y la cantidad de clientes para ver si vale la pena dejar la conexión abierta. Si usted es un sistema de dos niveles y tiene miles de clientes activos, entonces probablemente no quiera mantenerlos todos abiertos ... si usted es un sistema de dos niveles y solo tiene unas pocas docenas de clientes, entonces manténlos abiertos. .
Abra y cierre su conexión por operación comercial
Si está hablando de una aplicación cliente / servidor, recomendaría cerrar cada conexión tan pronto como haya terminado de usarla. Si bien cada instancia de aplicación individual puede tener un pequeño impacto de rendimiento al abrir la conexión, su aplicación como un todo escalará mejor. Esto es algo dependiente del servidor de base de datos que está utilizando. SQL Server manejará diferentes números de conexiones concurrentes basadas en el hardware en el que está instalado. Si desea escalar una aplicación de cliente / servidor a miles de computadoras de escritorio, un pequeño servidor de base de datos puede no manejar todos esos escritorios con conexiones abiertas, pero podría manejar miles de escritorios con solo algunas de las conexiones abiertas.
Vi esto de primera mano hace unos años. Una aplicación que se implementó en unos pocos departamentos sin problemas se implementó en toda la organización. La aplicación pronto fue muy, muy lenta. La organización estaba considerando comprar un pedazo de hardware muy caro para su servidor de base de datos para obtener algún rendimiento. Recomiendo que abran y cierren la conexión db después de cada operación comercial. Afortunadamente, habían diseñado la aplicación para que no fuera un cambio difícil. Hicieron el cambio y lo lanzaron durante una de sus actualizaciones de red semanales. De la noche a la mañana el rendimiento de la aplicación había mejorado significativamente. Ahorraron miles de dólares.