Pool de conexiones

El pool de conexiones es una técnica usada en aplicaciones Web para mejorar el rendimiento de éstas.

Antes de ver en que consiste veamos como funciona la creación de conexiones en una aplicación clásica de escritorio cliente-servidor y luego veamos los problemas se seguir con dicha estructura en una aplicación web.

En una aplicación de escritorio se crea una conexión de base de datos al iniciar la aplicación y se cierra al finalizar la aplicación. Es decir que cada usuario que inicia la aplicación tiene una conexión en exclusiva para él. Y obviamente sería imposible de compartirlas ya que cada aplicación estará en un ordenador independiente.

En una aplicación Web podríamos seguir un esquema similar , en el que cada usuario nuevo que se conecta a nuestra aplicación se le crea una conexión y al salir de la aplicación que se cierre la conexión.

Esto que aparentemente es sencillo tiene unos problemas debido a la diferente naturaleza de las aplicaciones de escritorio y las web.

Si siguiéramos el mismo patrón de creación de conexiones de aplicaciones de escritorio en aplicaciones web acabaríamos con una cantidad enorme de conexiones activas (debido al gran número de usuarios) y con gran cantidad de conexiones abiertas sin usar (debido a usuarios que abandonan el portal y no lo hemos detectado)

Consecuencia de los anterior al tener tantas conexiones a la base de datos se acabaría cayendo el servidor de base de datos debido a los recursos consumidos por todas las conexiones.

Podemos pensar que nuestro servidor puede aguantar todas esas conexiones debido que tenemos pocos usuarios pero no suele ser así debido a:

• Si no se cierran las conexiones aun teniendo pocos usuarios se llenaría de conexiones sin usar.
• Las aplicaciones Web pueden tener picos de mucho tráfico (como las épocas de matriculación) donde se excedería la capacidad de nuestro servidor.
• Sería muy sencillo hacernos un ataque de denegación de servicio y tumbarnos el servidor haciéndonos que creáramos gran cantidad de conexiones que no se usaran.

Una solución chapuza que nos evitaría las conexiones sin usar sería creara la conexión al iniciar cada petición web y cerrarla al finalizar dicha petición web. ¿El problema de eso? Crear y cerrar una conexión es muy costoso. Lo que tendríamos es una aplicación lentísima.

La solución del pool de conexiones tiene que solucionar dos problemas:

• No tener tantas conexiones como usuarios ya que el nº de usuarios es demasiado elevado.
• Cerrar la conexión.

La solución de cerrar la conexión se solucionaría fácilmente con la técnica de crearla al inicio de la petición y de cerrarla al final de la petición. Pero como ya hemos visto tiene el problema de lo lenta que sería la aplicación. Pero eso se puede solucionar con el Pool de conexiones

Así que por fin pasemos a explicar en que consiste el pool de conexiones:

El pool de conexiones consiste en tener un conjunto (pool) de conexiones a la base de datos que puedan ser reutilizadas entre distintas peticiones.

Veamos como funciona:

• El servidor web tiene “n” conexiones ya creadas y conectadas a la base de datos (El pool de conexiones).
  • Cuando llega una petición web la aplicación pide una conexión al pool de conexiones,quedando libre en el pool “n-1” conexiones. Esta operación es muy rápida ya que la conexión ya está creada y solo hay que marcarla como que alguien la está usando.
  • Cuando la petición web finaliza, la conexión no se cierra sino que se devuelve al pool indicándole que ya se ha acabado de usar la conexión. Ahora vuelve a quedar “n” conexiones libres en el pool. Esta operación también es muy rápida ya que realmente no se cierra sino que simplemente se marca como que ya no la está usando nadie.
• Si se pide más conexiones de las que hay en el pool se creará en ese instante una nueva conexión hasta el máximo de conexiones que permita el pool
• Al devolver una conexión al pool se queda libre para que otra petición la pueda usar. Si hay ya demasiadas conexiones esperando a ser usadas se cerrarán para ahorrar recursos en el servidor de base de datos.

¿Que hemos conseguido con el pool?

• Ahora las conexiones ya no se quedarán abiertas cuando el usuario se marcha del portal ya que cada conexión se pseudoabre y pseudocierra con cada petición.
• No tenemos tantas conexiones como usuarios usan la aplicación ya que solo se necesitan tantas como usuarios hay haciendo una petición en ese instante. Pensemos por un momento en facebook. ¿cuandos usuarios están conectados a facebook? Supongamos “n”. Pero ¿cuantos están realmente haciendo una petición y no viendo los datos que se han servido? Supongamos “m”. Obviamente “m” es mucho menor que “n”. Con lo que nos hemos ahorrado “n-m” conexiones.

En la siguiente gráfica vemos como evolucionan las conexiones de una aplicación web:

Desde Java podemos acceder al pool de conexiones usando la interfaz javax.sql.DataSource. Al llamar al método getConnection() se obtendrá una conexión del pool de conexiones y no se creará nueva en ese momento. Cuando llamemos al método java.sql.Connection.close() realmente la conexión no se cerrará sino que se devolverá al pool de conexiones.

DataSource dataSource;
Connection connection=dataSource.getConnection(); //Obtener la conexión del pool
 
//Usar la conexión
 
connection.close(); //No se cierra realmente la conexión sino que se retorna al pool

Ahora nos queda saber como obtener un objeto DataSource. Para obtener un objeto DataSource necesitamos primero configurar el pool de conexiones mediante el fichero context.xml, cosa que vamos a ver en el siguiente apartado. Ahora simplemente debemos saber que en un mismo servidor web puede haber muchos pool de conexiones por lo que cada uno de ellos tiene un nombre único. Para obtener el DataSource asociado a un pool de conexiones debemos incluir el siguiente código:

InitialContext initCtx=new InitialContext();;
Context envCtx = (Context) initCtx.lookup("java:comp/env");
DataSource ds = (DataSource)envCtx.lookup("jdbc/hibernate1");

Siendo jdbc/hibernate1 el nombre del pool de conexiones.

Por último nos queda configurar el pool de conexiones. Cada servidor web puede usar su propia implementación del pool de conexiones y se configura de forma específica. Nosotros vamos a explicar como configurar el pool que viene incluido en Tomcat 7.

El pool se configura añadiendo un fichero llamado context.xml en la carpeta META-INF.

 1: <?xml version="1.0" encoding="UTF-8"?>
 2: <Context path="/ejemplo05">
 3:     <Resource
 4:         type="javax.sql.DataSource"
 5:         auth="Container"
 6:         name="jdbc/hibernate1"
 7:         driverClassName="com.mysql.jdbc.Driver"
 8:         url="jdbc:mysql://localhost:3306/hibernate1"
 9:         username="hibernate1"
10:         password="hibernate1"
11:
12:         maxActive="100"
13:         maxIdle="30"
14:         maxWait="10000"
15:         validationQuery="SELECT 1 FROM dual"
16:      />
17: </Context>

• La líneas 4 y 5 indica que este recurso que estamos creando es un pool de conexiones.
• El atributo 'name' de la línea 6 indica el nombre del pool de conexiones que el el nombre que usamos en la línea de Java envCtx.lookup(name)
• El atributo 'driverClassName' de la línea 7 indica la FQCN del driver de JDBC que vamos a usar para conectarnos a la base de datos.
• El atributo 'url' de la línea 8 indica la URL de conexión a la base de datos
• El atributo 'username' de la línea 9 indica el usuario de conexión a la base de datos
• El atributo 'password' de la línea 10 indica la contraseña de conexión a la base de datos

Hasta ahora solo hemos indicado los atributo básicos de conexión a la base de datos, veamos ahora los atributos concretos del pool:

• El atributo 'maxActive' de la línea 12 indica el número máximo de conexiones que pueden usarse. Esto indicará el nº máximo de usuarios que podrá haber a la vez haciendo peticiones.Si hay más usuarios se producirá un error indicando que ya no hay conexiones.
• El atributo 'maxIdle' de la línea 13 indica el número máximo de conexiones libres que puede haber esperando a que llegue un usuario para usarlas. Si hay demasiadas conexiones libres Tomcat empezará a cerrarlas hasta llegar al valor maxIdle para ahorrar recursos del servidor de base de datos.
• El atributo 'maxWait' de la línea 14 indica el tiempo en ms que esperará Tomcat a que haya una conexión libre en caso de que no hubiera ninguna libre en ese instante.
• El atributo 'validationQuery' de la línea 15 indica una SQL de tipo SELECT que lanza Tomcat para comprobar que la conexión aun está conectada a la base de datos y que ésta ultima no la ha cerrado unilateralmente.