Almacenar una conexión JDBC en HttpSession

Question

He heredado recientemente un código, dentro del cual encontré que se inicializó una conexión JDBC en un filtro y agregué la HttpSession para cada usuario. Esa conexión se reutiliza a lo largo de varias partes de la aplicación web para el usuario. Esto inmediatamente se destacó para mí como un olor a código. Me gustaría volver con el desarrollador que lo escribió y explicar por qué no debería hacerlo ... Pero tal vez no estoy tan seguro de mí ...

Además de ocupar espacio innecesario en la memoria y potencialmente limitando las conexiones disponibles a la base de datos, ¿hay alguna otra razón por la cual no almacenaría una conexión JDBC en una sesión?

Answer 1

Ha mencionado lo obvio, una conexión de base de datos de usuario a uno no es escalable. Sus usuarios deben estar completamente desacoplados del acceso al modelo de datos. Aquí hay un par de problemas con los que se encontrará.

• ¿Qué sucede si la conexión se vuelve obsoleta? Ese usuario no podrá hacer nada útil sin una conexión a la base de datos, por lo que es probable que deba desconectarse y volver a conectarse para obtener una nueva conexión. loca.
• Las conexiones JDBC no son seguras para hilos. Si un usuario decide ejecutar un par de cosas a la vez, se desatará el infierno.

Answer 2

Toda la idea de mantener las conexiones JDBC tan arriba en la pila como en HttpSession o incluso el acceso a las conexiones JDBC en la capa de servlet no tiene mucho sentido. Tiene mucho más sentido agrupar las conexiones en el servidor de aplicaciones y reducir la cantidad de conexiones abiertas de esa manera. La misma aplicación puede servir a usuarios mucho más simultáneos con un rendimiento mucho mejor.

En una aplicación grande, es poco probable que todas las solicitudes lleguen a la base de datos, ya que la misma información probablemente se encuentre en la memoria caché.

En un entorno agrupado con sesiones no adhesivas, la conexión JDBC no sería válida incluso si la solicitud tocase en otra casilla distinta a aquella en la que se creó la sesión.

En general, debe almacenar solo información específica del usuario en la sesión e incluso reducir al mínimo la cantidad necesaria en sesiones. Más datos en sesión significan más datos para transferir entre los servidores de aplicaciones en un clúster cuando se replican las sesiones (en caso de que las sesiones no se almacenen en una base de datos central o caché).

Answer 3

Aunque no tengo forma de saberlo, me atrevo a suponer que su colega comenzó con cada solicitud obteniendo una nueva conexión propia del administrador, al igual que en los programas de principiante y de demostración. Pronto descubrió que esto ralentizaba las solicitudes dramáticamente; así que ahora está evitando la creación de conexiones al "agruparlas" en sesiones de usuario.

Esto resuelve el problema de rendimiento para los usuarios que hacen una segunda y posteriores solicitudes en una conexión, pero es una solución muy incómoda y no escalable. Si la base de usuarios de su aplicación aumenta, la cantidad de usuarios con sesiones abiertas superará rápidamente la cantidad máxima de conexiones que su BD puede proporcionarle. Y luego hay problemas con el tiempo de espera de las conexiones de las sesiones o de la base de datos ...

La solución "estándar de la industria" es usar la agrupación de conexiones. Las versiones modernas de Tomcat tienen la agrupación de conexiones "integrada", al igual que otros servidores de aplicaciones web. Si no, puede instalar fácilmente el suyo. Esto le permite administrar un conjunto de conexiones completamente independiente de las sesiones de usuario.

Otro beneficio de la agrupación de conexiones es que, una vez que la agrupación se "calienta", es decir,varias conexiones están en uso e inicializadas, incluso las "primeras solicitudes por sesión de usuario" reciben una conexión rápidamente. Por lo tanto, el rendimiento global mejorará con respecto a su situación actual.