1
00:00:00,180 --> 00:00:04,380
Bienvenidos, continuamos con una pequeña introducción de pool de conexiones, hasta momento hemos estado

2
00:00:04,380 --> 00:00:09,300
trabajando y montado, conectando la Sedatu, utilizando el DRAE manager con el método que Connection

3
00:00:09,450 --> 00:00:10,860
y establecemos una conexión.

4
00:00:10,950 --> 00:00:16,410
Pero qué pasa cuando ya nuestra aplicación en multiusuario con varios sílo que realizan distintas consultas,

5
00:00:16,410 --> 00:00:21,780
operaciones, sentencias, incluso transacciones al mismo tiempo podríamos tener un problema, ya que

6
00:00:21,780 --> 00:00:26,370
si no sincronizamos todas las transacciones que se están ejecutando prácticamente al mismo tiempo,

7
00:00:26,400 --> 00:00:28,680
podríamos tener inconsistencia en los datos.

8
00:00:28,800 --> 00:00:34,140
La información que se envía y que reciben los distintos hilos se podrían entremezclar y al final vamos

9
00:00:34,140 --> 00:00:37,260
a tener inconsistencia en toda la información de nuestro sistema.

10
00:00:37,410 --> 00:00:38,820
Acá tenemos diferente alternativa.

11
00:00:38,880 --> 00:00:45,250
Una claro, podríamos mantener esta misma conexión compartida por todos los usuarios o los hilos, pero

12
00:00:45,360 --> 00:00:49,360
tendríamos que sincronizar con todo lo que es manejo de hilo con sincronice.

13
00:00:49,410 --> 00:00:54,570
Sincronizar estos métodos que ejecuta, sentencia, transacciones, pero tendría un inconveniente.

14
00:00:54,780 --> 00:01:00,150
Recuerden que cada que un hilo utiliza un método sincronizado, el resto que lo quiere utilizar tiene

15
00:01:00,150 --> 00:01:00,630
que esperar.

16
00:01:00,720 --> 00:01:05,670
Entonces va a haber un tiempo, un delay de espera y eso podría hacer que nuestra aplicación funcione

17
00:01:05,790 --> 00:01:06,780
un poco más lento.

18
00:01:06,960 --> 00:01:12,510
Pero bueno, otra alternativa es que cada hilo tenga su propia conexión al acetato, es decir, que

19
00:01:12,540 --> 00:01:17,850
requiera una crea una conexión directa la Segato con el Drive Manager, con el que con hecho claro,

20
00:01:17,850 --> 00:01:19,350
con pocos usuarios no hay problema.

21
00:01:19,380 --> 00:01:24,510
Pero si son muchos usuarios que están creando conexiones, que se están conectando todo al mismo tiempo,

22
00:01:24,600 --> 00:01:31,620
recuerden crear una conexión a la SEA con JS es costoso, requiere recursos de sistema cuando se crean

23
00:01:31,620 --> 00:01:37,080
y se crean conexiones y se cierran sin ningún tipo de límites, sin ningún tipo de manejo.

24
00:01:37,170 --> 00:01:40,410
Podríamos tener finalmente un cuello de botella en nuestro sistema.

25
00:01:40,560 --> 00:01:42,000
No podría quedar sin recurso.

26
00:01:42,120 --> 00:01:45,270
La aplicación se podría caer o incluso andar bastante lento.

27
00:01:45,300 --> 00:01:51,150
Entonces, una tercera solución sería un pulso de conexiones, la más óptima en sistema multiusuario.

28
00:01:51,270 --> 00:01:56,610
Bueno, típicamente todo lo que es aplicaciones web donde un cliente o un usuario mediante un navegador

29
00:01:56,700 --> 00:02:02,250
o una aplicación cliente realiza un rico es una solicitud al servidor HTTP.

30
00:02:02,370 --> 00:02:07,830
Donde está nuestra aplicación Loire que sea una conexión por cliente por usuario que se conecta.

31
00:02:08,040 --> 00:02:12,270
Pero si tenemos un público misione ya tiene un conjunto de conexiones creadas.

32
00:02:12,390 --> 00:02:16,560
No tenemos que estar creando conexiones cada vez que se conecte un usuario, no, ya están creadas tan

33
00:02:16,650 --> 00:02:17,190
habilitadas.

34
00:02:17,190 --> 00:02:21,960
Simplemente el usuario la utiliza y después se preocupa de cerrarla con el método Close.

35
00:02:22,020 --> 00:02:26,790
Pero después vamos a ver que no es que la cierre, no es que te cerrando la conexión, sino lo que hace

36
00:02:26,790 --> 00:02:33,360
es indicar al manejador de conexiones a este pull que libera el recurso que deja disponible la conexión

37
00:02:33,390 --> 00:02:36,030
para que otro usuario, otro hilo la pueda utilizar.

38
00:02:36,180 --> 00:02:36,750
Y eso es todo.

39
00:02:36,840 --> 00:02:41,460
Entonces finalmente estamos reutilizando conexiones que ya están creadas y no estamos desperdiciando

40
00:02:41,460 --> 00:02:44,400
recursos en crear conexiones cada que un usuario se conecta.

41
00:02:44,730 --> 00:02:50,100
Entonces, para resumir, un pull de conexiones es una clase DataSource de Java que mantiene abierta

42
00:02:50,190 --> 00:02:54,550
un conjunto limitado de conexiones al Seaton y estas son administrada por esta API.

43
00:02:54,690 --> 00:03:00,140
De esta forma, si un usuario un hilo requiere una conexión a la base dato en vez de Arilla o crearla

44
00:03:00,150 --> 00:03:06,390
de forma directa con el dragón manager con el que Connection se le pide conexión al pool usando el método

45
00:03:06,510 --> 00:03:12,420
del DataSource de estipule the manejador el método que conecta con el pull selecciona una de las conexiones

46
00:03:12,420 --> 00:03:14,430
que ya están abiertas y disponible.

47
00:03:14,550 --> 00:03:20,280
Se la pasa al hilo y la deja marcada como ocupada para no entregársela a otro hilo más.

48
00:03:20,460 --> 00:03:21,330
Veamos un esquema.

49
00:03:21,420 --> 00:03:22,940
Acá tenemos Varrick cliente.

50
00:03:23,040 --> 00:03:27,450
Pueden ser n cantidad de cliente y todos piden una conexión a este pull.

51
00:03:27,570 --> 00:03:31,860
El manejador de conexiones ya tiene cierto número de conexiones creadas.

52
00:03:31,990 --> 00:03:34,980
Bueno, y por supuesto que por debajo utiliza el drive manager.

53
00:03:35,100 --> 00:03:37,430
No lo vemos, pero si lo utiliza y todo.

54
00:03:37,440 --> 00:03:41,010
Esta conexiones ya tienen una comunicación directa con ese dato.

55
00:03:41,100 --> 00:03:42,780
Es decir, simplemente la utilizamos.

56
00:03:42,900 --> 00:03:46,410
Veamos algunos ejemplo de cómo crear un pull de conexiones.

57
00:03:46,530 --> 00:03:47,010
Bueno, ahí va.

58
00:03:47,010 --> 00:03:54,270
La implementación es la más típica de Apache Commons Database Connection Pull o DB CP 2.

59
00:03:54,360 --> 00:03:59,400
Por supuesto que necesitamos un string de conexión a la base rato con el Yussef Nem y el password.

60
00:03:59,550 --> 00:04:06,210
Y a partir de estos parámetros, el pool se encarga de manejar cierto número limitado de conexiones

61
00:04:06,360 --> 00:04:11,490
y para eso configuramos parámetro, por ejemplo, el tamaño del pool inicial con el método set.

62
00:04:11,550 --> 00:04:17,340
Hay Nichol 6, por ejemplo, inicialmente creando 3 conexiones habilitadas al hace rato, pero si después

63
00:04:17,340 --> 00:04:22,860
la cantidad de hilos concurrentes empieza a aumentar y requiere más conexiones, se pueden ir aumentando

64
00:04:22,860 --> 00:04:29,340
la cantidad de conexiones en el pool hasta tener un máximo que puedo configurar con el set max total.

65
00:04:29,490 --> 00:04:34,260
Es decir, con eso tal hacemos el máximo de conexiones en el pool, pero siempre podemos partir de un

66
00:04:34,260 --> 00:04:38,940
tamaño inicial que va a ir creciendo de acuerdo a la cantidad concurrencia que vamos a tener.

67
00:04:39,090 --> 00:04:45,570
Luego tenemos los parámetros Min y Max ITel que la cantidad mínima y máxima de conexiones inactiva.

68
00:04:45,840 --> 00:04:48,900
Veamos un ejemplo de uso de una conexión del pool.

69
00:04:49,050 --> 00:04:52,050
Es decir, como podemos solicitar pedir una conexión del pool?

70
00:04:52,170 --> 00:04:56,790
Bueno, ya tenemos creado el pool simplemente invocando el método Get Connection de este DataSource

71
00:04:56,880 --> 00:04:59,940
o Basic DataSource obtenemos una conexión.

72
00:05:00,240 --> 00:05:05,580
Disponible y con esta conexión podemos trabajar, ejecutar sentencias, transacciones, lo típico que

73
00:05:05,580 --> 00:05:11,180
hemos visto select a de insert de lit con el pre préstenme con el stamm en el result set.

74
00:05:11,310 --> 00:05:16,200
Pero si al final tenemos que preocuparnos de cerrar esta conexión para que pueda ser utilizada por otro

75
00:05:16,200 --> 00:05:20,220
hilo para que quede disponible en el pool, entonces con el metodo Clowes la cerramos.

76
00:05:20,280 --> 00:05:25,230
Pero en realidad no es que la estemos cerrando, sino le estamos indicando con el método Close al pull

77
00:05:25,230 --> 00:05:29,670
de conexión que liberamos la conexión para su próxima reutilización.

78
00:05:29,790 --> 00:05:32,340
Bien, continuamos la siguiente clase con un ejemplo.