2008-11-19 12 views
5

Todo el mundo sabe que debe cerrar una conexión inmediatamente después de que termine de usarla.¿Es aceptable mantener abierta una conexión de db durante la vida de la página?

Debido a un error en el diseño de mi modelo de objetos de dominio, tuve que dejar la conexión abierta para el ciclo de vida de la página completa. Básicamente, tengo una propiedad Just In Time que abre una conexión en la primera llamada, y luego en la página. Descargar (...) verificará si alguna vez se abrió una conexión db y luego la cerrará si fuera así. Como solo lleva un segundo, tengo la opinión de que no es demasiado diferente de cerrarlo de inmediato.

¿Esto está bien? ¿O debería cerrarse inmediatamente después de cada uso individual?

Gracias de antemano.

+0

¿Quiere decir que la conexión se mantiene abierta entre las post-backs? – MusiGenesis

+0

No, la conexión db está abierta en la carga de página (...) o posterior, y luego se cierra en el evento Page.Unload (...). –

+0

Voy a editar mi respuesta, gracias. – MusiGenesis

Respuesta

1

No es ideal, pero no volvería a escribir mi aplicación sobre él.A menos que su página esté realizando una gran cantidad de trabajo que requiere mucho tiempo en varios métodos, el ciclo de vida completo de la página debería ejecutarse rápidamente. En la práctica, puede significar que su objeto de conexión está abierto unos milisegundos más de lo que hubiera sido de otra manera. Eso podría ser significativo en algunos escenarios, pero no parece serlo en su caso.

+0

Page.Load (..) open, Page.Unload (..) close. –

+0

Justo lo que pienso, pero creo que hay muchos puristas aquí. –

+4

Los puristas se parecen mucho a los instructores de West Point (la academia del ejército de EE. UU.). Gran parte de lo que dicen se olvida rápidamente cuando las balas comienzan a volar. – MusiGenesis

2

Sí, está bien.

Cerrar la conexión tan pronto como pueda es una práctica recomendada para evitar conexiones abiertas huérfanas, pero si está seguro de que la conexión está cerca, no hay nada de malo en eso.

+0

Nunca mantenga una conexión abierta. La aplicación nunca se escalará porque usará recursos cuando no los necesite. La agrupación de conexiones es algo que se resolvió hace mucho tiempo. – chilltemp

+1

¡Vamos! Esta es una aplicación real, con un problema real, en un mundo real, y dice que la aplicación nunca crecerá más de 100 usuarios. –

3

¿Qué sucede si la página se bloquea antes de llegar al evento Page.Unload? Tendrás una conexión abierta. Para mí, es mejor cerrar siempre la conexión lo antes posible.

7

No, no está bien.

Si su aplicación necesita alguna vez crecer o escalar, querrá solucionar este problema. Al mantener abierta esa conexión, reduces tu capacidad de escalar. Tenga en cuenta que las conexiones abiertas ocupan memoria en el servidor, la memoria en el cliente, mantienen bloqueos abiertos, etc.

+0

Gracias Scott, esta aplicación en particular nunca escalará más allá de 100 uers. –

1

¿cuelga la página? esto es lo que usa y finalmente es para

dicho, por el bien del rendimiento de la base de datos (es decir, escalado) * es mejor mantener las conexiones abiertas el menor tiempo posible, permitiendo solo que no se desee abrir cerrar abierto cerrar apertura y cierre rápido para el trabajo secuencial y predecible

* me dijeron que esto por un mentor al principio de mi carrera, debo decir que no he probado esto en realidad a mí mismo, pero suena bien en teoría

+0

La agrupación de conexiones ayudará con el escenario donde abre y cierra muchas conexiones. –

+0

Creo que el problema para John es que su arquitectura, por cualquier razón, impide utilizar/finalmente porque open está en PageLoad y PageUnload. – Ted

+0

Pero yo diría que es un problema de diseño fundamental: contradice mantener la duración de la conexión lo más corta posible – annakata

2

Cada decente ASP. La aplicación NET utiliza la agrupación de conexiones hoy en día, y un grupo es básicamente un grupo de conexiones abiertas. En su caso, eso significaría que la conexión a la que está retenido está "ocupada" y no puede utilizarse para atender otras solicitudes.

Por lo que veo, sería un problema de escalabilidad dependiendo de la cantidad de tiempo que su página necesita para trabajar/renderizar. Si solo espera 100 usuarios, como usted dice, entonces probablemente no sea un problema, a menos que sea 100 req/seg por supuesto.

Desde el punto de vista tecnológico, está bien. Por lo que recuerdo, la mayoría de las aplicaciones cliente-servidor (web y no web), incluido el clásico código ASP, solían funcionar así, por ejemplo, declaras una conexión para toda la página y trabajas con ella.

1

Por supuesto que puede mantenerlos abiertos, pero no, no. Ciérrelo después de su uso en los bloques finalmente. Una transacción justa desde "después de cada uso único" es cerrarlo después de cada bloque de uso, si puede ejecutar un proceso almacenado, actualizar una columna y luego eliminar alguna otra fila, puede abrir/cerrar alrededor de esos tres operaciones, suponiendo que están todos envueltos en un try/catch/finally.

+0

"suponiendo que todos están envueltos en una prueba/captura/finalmente" - o más probable y probablemente mejor, una prueba/finalmente o usando la declaración. – Joe

1

Sin duda, debe mantener la conexión abierta durante toda la vida de la página, si está realizando múltiples consultas durante la misma. En general, uno reutiliza las conexiones en muchas páginas, en realidad.

1

Creo que una mejor pregunta con comentarios mucho más informados y productivos sería proporcionar algunos fragmentos de lo que estás haciendo (código) y ampliar las razones por las que has hecho esta elección. Es muy probable que haya una solución mejor que no requiera mantener la conexión abierta por tanto tiempo, pero al menos, por razones pragmáticas, puede obtener algunos comentarios sobre si vale la pena modernizarla.

En el futuro, definitivamente desea alejarse del acceso a los datos en su código subyacente.

1

Encuentro que es conveniente mantener la conexión abierta cuando se usa ORM (Open Session in View) para que después de una búsqueda inicial con ganas, otros datos se puedan cargar de forma diferida según sea necesario. Esto funciona bien cuando los tiempos de respuesta de la página son razonables para no vincular las conexiones.

Cuestiones relacionadas