Usar un pool de conexiones a base de datos

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.