Bienvenidos, continuamos con una pequeña introducción de pool de conexiones, hasta momento hemos estado
trabajando y montado, conectando la Sedatu, utilizando el DRAE manager con el método que Connection
y establecemos una conexión.
Pero qué pasa cuando ya nuestra aplicación en multiusuario con varios sílo que realizan distintas consultas,
operaciones, sentencias, incluso transacciones al mismo tiempo podríamos tener un problema, ya que
si no sincronizamos todas las transacciones que se están ejecutando prácticamente al mismo tiempo,
podríamos tener inconsistencia en los datos.
La información que se envía y que reciben los distintos hilos se podrían entremezclar y al final vamos
a tener inconsistencia en toda la información de nuestro sistema.
Acá tenemos diferente alternativa.
Una claro, podríamos mantener esta misma conexión compartida por todos los usuarios o los hilos, pero
tendríamos que sincronizar con todo lo que es manejo de hilo con sincronice.
Sincronizar estos métodos que ejecuta, sentencia, transacciones, pero tendría un inconveniente.
Recuerden que cada que un hilo utiliza un método sincronizado, el resto que lo quiere utilizar tiene
que esperar.
Entonces va a haber un tiempo, un delay de espera y eso podría hacer que nuestra aplicación funcione
un poco más lento.
Pero bueno, otra alternativa es que cada hilo tenga su propia conexión al acetato, es decir, que
requiera una crea una conexión directa la Segato con el Drive Manager, con el que con hecho claro,
con pocos usuarios no hay problema.
Pero si son muchos usuarios que están creando conexiones, que se están conectando todo al mismo tiempo,
recuerden crear una conexión a la SEA con JS es costoso, requiere recursos de sistema cuando se crean
y se crean conexiones y se cierran sin ningún tipo de límites, sin ningún tipo de manejo.
Podríamos tener finalmente un cuello de botella en nuestro sistema.
No podría quedar sin recurso.
La aplicación se podría caer o incluso andar bastante lento.
Entonces, una tercera solución sería un pulso de conexiones, la más óptima en sistema multiusuario.
Bueno, típicamente todo lo que es aplicaciones web donde un cliente o un usuario mediante un navegador
o una aplicación cliente realiza un rico es una solicitud al servidor HTTP.
Donde está nuestra aplicación Loire que sea una conexión por cliente por usuario que se conecta.
Pero si tenemos un público misione ya tiene un conjunto de conexiones creadas.
No tenemos que estar creando conexiones cada vez que se conecte un usuario, no, ya están creadas tan
habilitadas.
Simplemente el usuario la utiliza y después se preocupa de cerrarla con el método Close.
Pero después vamos a ver que no es que la cierre, no es que te cerrando la conexión, sino lo que hace
es indicar al manejador de conexiones a este pull que libera el recurso que deja disponible la conexión
para que otro usuario, otro hilo la pueda utilizar.
Y eso es todo.
Entonces finalmente estamos reutilizando conexiones que ya están creadas y no estamos desperdiciando
recursos en crear conexiones cada que un usuario se conecta.
Entonces, para resumir, un pull de conexiones es una clase DataSource de Java que mantiene abierta
un conjunto limitado de conexiones al Seaton y estas son administrada por esta API.
De esta forma, si un usuario un hilo requiere una conexión a la base dato en vez de Arilla o crearla
de forma directa con el dragón manager con el que Connection se le pide conexión al pool usando el método
del DataSource de estipule the manejador el método que conecta con el pull selecciona una de las conexiones
que ya están abiertas y disponible.
Se la pasa al hilo y la deja marcada como ocupada para no entregársela a otro hilo más.
Veamos un esquema.
Acá tenemos Varrick cliente.
Pueden ser n cantidad de cliente y todos piden una conexión a este pull.
El manejador de conexiones ya tiene cierto número de conexiones creadas.
Bueno, y por supuesto que por debajo utiliza el drive manager.
No lo vemos, pero si lo utiliza y todo.
Esta conexiones ya tienen una comunicación directa con ese dato.
Es decir, simplemente la utilizamos.
Veamos algunos ejemplo de cómo crear un pull de conexiones.
Bueno, ahí va.
La implementación es la más típica de Apache Commons Database Connection Pull o DB CP 2.
Por supuesto que necesitamos un string de conexión a la base rato con el Yussef Nem y el password.
Y a partir de estos parámetros, el pool se encarga de manejar cierto número limitado de conexiones
y para eso configuramos parámetro, por ejemplo, el tamaño del pool inicial con el método set.
Hay Nichol 6, por ejemplo, inicialmente creando 3 conexiones habilitadas al hace rato, pero si después
la cantidad de hilos concurrentes empieza a aumentar y requiere más conexiones, se pueden ir aumentando
la cantidad de conexiones en el pool hasta tener un máximo que puedo configurar con el set max total.
Es decir, con eso tal hacemos el máximo de conexiones en el pool, pero siempre podemos partir de un
tamaño inicial que va a ir creciendo de acuerdo a la cantidad concurrencia que vamos a tener.
Luego tenemos los parámetros Min y Max ITel que la cantidad mínima y máxima de conexiones inactiva.
Veamos un ejemplo de uso de una conexión del pool.
Es decir, como podemos solicitar pedir una conexión del pool?
Bueno, ya tenemos creado el pool simplemente invocando el método Get Connection de este DataSource
o Basic DataSource obtenemos una conexión.
Disponible y con esta conexión podemos trabajar, ejecutar sentencias, transacciones, lo típico que
hemos visto select a de insert de lit con el pre préstenme con el stamm en el result set.
Pero si al final tenemos que preocuparnos de cerrar esta conexión para que pueda ser utilizada por otro
hilo para que quede disponible en el pool, entonces con el metodo Clowes la cerramos.
Pero en realidad no es que la estemos cerrando, sino le estamos indicando con el método Close al pull
de conexión que liberamos la conexión para su próxima reutilización.
Bien, continuamos la siguiente clase con un ejemplo.