You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
La gestión actual de conexiones a base de datos presenta varios problemas.
Por un lado, en la versión 2.3 que es la actual estable, el DbManager mantiene una sola conexión a base de datos, pero la lógica de gestionar cuando la conexión es válida en el método getConnection no es "thread safe", y da problemas cuando hay concurrencia. En nuestras pruebas de preproducción generando una simulación con 3 usuarios concurrentes ya se generan varias excepciones de peticiones que no se pueden completar porque la conexión a base de datos es null.
Vemos que en la versión 2.4, todavía en desarrollo, se ha cambiado el DbManager para obtener conexiones nuevas cada vez que se necesitan. Aunque esta aproximación es mejor, implica que cada thread obtiene su conexión, no es una solución muy eficiente. Las conexiones son costosas de crear y ocupan muchos recursos. También en entornos de mucha concurrencia se puede dar el caso, que se deba ajustar el número de threads con que opera el Tomcat al número máximo de conexiones que puede soportar la base de datos.
En estos casos la mejor aproximación es gestionar un pool de conexiones con un DataSource. Todos los servidores de aplicaciones, y también Tomcat tienen los mecanismos para crear un pool de conexiones a base de datos, y asignarle un nombre JNDI. En la configuración del componente fire-signature (config.properties) o del módulo fire-admin-jsp (admin_config.properties), se podrian cambiar las actuales propiedades, bbdd.driver y bbdd.conn, por una sola bbdd.jndi, con el nombre JNDI del datasource creado en el servidor de aplicaciones.
En la configuración del datasource cada instalación podrá configurar, que número máximo de conexiones quiere, cual es el tiempo máximo de espera si no quedan conexiones disponibles, que métodos usas para comprobar que las conexiones son validas antes de retornarlas, descargando toda esa logica del DbManger que se limitaría a retornar una conexión del datasource. También los datasources suelen permitir definir parámetros o comportamientos adicionales que ahora no se permiten. Por ejemplo, sentencias SQL para fijar parámetros de sessión de la base de datos que deban ejecutarse cada vez que se obtiene una nueva conexión.
The text was updated successfully, but these errors were encountered:
La gestión actual de conexiones a base de datos presenta varios problemas.
Por un lado, en la versión 2.3 que es la actual estable, el
DbManager
mantiene una sola conexión a base de datos, pero la lógica de gestionar cuando la conexión es válida en el métodogetConnection
no es "thread safe", y da problemas cuando hay concurrencia. En nuestras pruebas de preproducción generando una simulación con 3 usuarios concurrentes ya se generan varias excepciones de peticiones que no se pueden completar porque la conexión a base de datos esnull
.Vemos que en la versión 2.4, todavía en desarrollo, se ha cambiado el
DbManager
para obtener conexiones nuevas cada vez que se necesitan. Aunque esta aproximación es mejor, implica que cada thread obtiene su conexión, no es una solución muy eficiente. Las conexiones son costosas de crear y ocupan muchos recursos. También en entornos de mucha concurrencia se puede dar el caso, que se deba ajustar el número de threads con que opera el Tomcat al número máximo de conexiones que puede soportar la base de datos.En estos casos la mejor aproximación es gestionar un pool de conexiones con un
DataSource
. Todos los servidores de aplicaciones, y también Tomcat tienen los mecanismos para crear un pool de conexiones a base de datos, y asignarle un nombre JNDI. En la configuración del componentefire-signature
(config.properties
) o del módulofire-admin-jsp
(admin_config.properties
), se podrian cambiar las actuales propiedades,bbdd.driver
ybbdd.conn
, por una solabbdd.jndi
, con el nombre JNDI del datasource creado en el servidor de aplicaciones.En la configuración del datasource cada instalación podrá configurar, que número máximo de conexiones quiere, cual es el tiempo máximo de espera si no quedan conexiones disponibles, que métodos usas para comprobar que las conexiones son validas antes de retornarlas, descargando toda esa logica del
DbManger
que se limitaría a retornar una conexión del datasource. También los datasources suelen permitir definir parámetros o comportamientos adicionales que ahora no se permiten. Por ejemplo, sentencias SQL para fijar parámetros de sessión de la base de datos que deban ejecutarse cada vez que se obtiene una nueva conexión.The text was updated successfully, but these errors were encountered: