1
00:00:00,150 --> 00:00:05,070
Bien, continuemos con un nuevo tema relacionado JS La transacciones es un concepto bien simple, se

2
00:00:05,070 --> 00:00:09,120
trata de ejecutar varias sentencias, operaciones, pero como si fueran una sola.

3
00:00:09,180 --> 00:00:14,940
Toda junta y si alguna de esta llega a fallar, la idea es que no se ejecute o no se realice ninguna.

4
00:00:15,120 --> 00:00:17,490
Es decir, que vuelva al estado anterior, que tenía la base.

5
00:00:17,490 --> 00:00:18,840
Dato que no modifique nada.

6
00:00:18,870 --> 00:00:20,430
Simplemente acá no pasó nada.

7
00:00:20,580 --> 00:00:25,560
Claro, porque muchas veces cuando están ejecutando un grupo de sentencias que están relacionadas unas

8
00:00:25,560 --> 00:00:29,070
con otra y por alguna razón una falla lanza un error.

9
00:00:29,200 --> 00:00:29,880
Bueno, qué pasa?

10
00:00:30,000 --> 00:00:32,250
Van a que los datos inconsistente en las tablas.

11
00:00:32,370 --> 00:00:36,570
Algunos datos van a quedar, pero los datos de otra tabla no van a quedar por el error, se fijan.

12
00:00:36,660 --> 00:00:38,760
Entonces queda en un estado inconsistente.

13
00:00:38,880 --> 00:00:42,420
Entonces, en ese caso necesitamos mecanismos que se ejecutan.

14
00:00:42,520 --> 00:00:47,100
En el fondo se ejecutan todas o ninguna y en caso de falla, devolver a su estado original.

15
00:00:47,220 --> 00:00:47,760
Y eso todo.

16
00:00:47,880 --> 00:00:49,650
Le enviamos una definición poco más formal.

17
00:00:49,740 --> 00:00:50,730
Entonces, una transacción.

18
00:00:50,790 --> 00:00:51,480
Es un conjunto.

19
00:00:51,480 --> 00:00:53,230
Operaciones, sentencias sobre la base.

20
00:00:53,250 --> 00:00:56,220
Dato que se deben ejecutar como una unidad de trabajo.

21
00:00:56,310 --> 00:00:58,510
Un solo bloque como si fuera una sola.

22
00:00:58,650 --> 00:00:58,980
Veámoslo.

23
00:00:58,980 --> 00:01:00,210
Concepto que hay detrás.

24
00:01:00,270 --> 00:01:05,730
Muy importante tener claro que si alguna llega a fallar en su ejecución de este bloque, cualquier sentencia

25
00:01:05,790 --> 00:01:10,830
podemos dar marcha atrás, volver con un rollback y justamente se realiza un rollback.

26
00:01:10,950 --> 00:01:16,590
Una llamada para que todo el bloque en ejecución que se está ejecutando vuelva a la original y todos

27
00:01:16,590 --> 00:01:19,920
los cambios que se habían hecho no surjan efecto, se reviertan.

28
00:01:20,040 --> 00:01:25,950
Y justamente cuando ocurre un error lo manejamos en el catch manejo excepciones y dentro del catch invocamos

29
00:01:26,040 --> 00:01:26,600
el rollback.

30
00:01:26,610 --> 00:01:27,120
Se fijan?

31
00:01:27,210 --> 00:01:30,060
Pero si todo sale bien, todo el bloque se ejecuta de forma correcta.

32
00:01:30,060 --> 00:01:30,870
No hay ningún problema.

33
00:01:30,900 --> 00:01:31,500
Perfecto.

34
00:01:31,620 --> 00:01:37,800
Realizamos un commit aplicando los cambios sobre la tabla que tan relacionada a este bloque trabajo.

35
00:01:37,830 --> 00:01:42,510
Entonces lo que hace el commit justamente es aplicar los cambios o guarda los cambios de todo el bloque

36
00:01:42,600 --> 00:01:43,230
ejecutado.

37
00:01:43,320 --> 00:01:47,610
Bueno, pero para implementar transacciones necesitamos seguir algunos pasos.

38
00:01:47,640 --> 00:01:50,310
Por ejemplo, cambiar la propiedad que es un atributo.

39
00:01:50,400 --> 00:01:53,910
El auto commit de la conexión a la auto por defecto es true.

40
00:01:54,000 --> 00:01:55,530
Lo tenemos que cambiar a fols.

41
00:01:55,620 --> 00:02:01,290
Porque por defecto siempre acá que se ejecuta una sentencia automáticamente se hace un commit automáticamente

42
00:02:01,330 --> 00:02:01,770
then true.

43
00:02:02,000 --> 00:02:03,030
Entonces lo que vemos en fols.

44
00:02:03,120 --> 00:02:06,030
Para que podamos manipular el commit de forma manual.

45
00:02:06,150 --> 00:02:11,520
Entonces, si todo sale bien en las sentencias del bloque, realizamos el commit para guardar los cambios

46
00:02:11,610 --> 00:02:15,990
en la Ayato, pero no solamente de una sentencia, sino de este conjunto dentro bloque.

47
00:02:16,140 --> 00:02:22,320
Recuerden, es una unidad, trajo un conjunto y siempre la idea es que la transacción esté asociada

48
00:02:22,440 --> 00:02:23,280
a un solo hilo.

49
00:02:23,460 --> 00:02:28,590
El problema que tenemos multiusuario o múltiplo y todos trabajan sobre la misma transacción sería un

50
00:02:28,590 --> 00:02:29,430
caos, no cierto?

51
00:02:29,510 --> 00:02:31,260
Claro, tiene que ser individual.

52
00:02:31,320 --> 00:02:33,390
Por eso se le llama una unidad de trabajo.

53
00:02:33,600 --> 00:02:34,530
Es un punto importante.

54
00:02:34,650 --> 00:02:37,320
Entonces los dos primeros paso es el auto commit en fours.

55
00:02:37,410 --> 00:02:42,540
Luego, si todo sale bien, realizamos un commit invocando el método commit del objeto connection.

56
00:02:42,660 --> 00:02:48,300
Ahora, si falla dentro del catch en el manejo de exepciones, realizamos o ejecutamos el método rollback

57
00:02:48,390 --> 00:02:53,820
para revertir los cambios al estado original que tenían las tablas de ese conjunto o bloqueÃ se fijan.

58
00:02:53,850 --> 00:02:56,640
Entonces invocamos el método rollback para regresar atrás.

59
00:02:56,760 --> 00:02:59,580
Y otro tema importante el auto commit es tan fols.

60
00:02:59,700 --> 00:03:06,060
Y en ninguna parte de nuestro código invocamos el método commit del objeto connection del objeto conexión.

61
00:03:06,150 --> 00:03:10,950
Cuando cerramos la conexión de la Ayato o cuando se cierre de forma automática con el auto Closs de

62
00:03:10,950 --> 00:03:16,110
forma automática también se va a realizar commit entonces siempre sí o si se va a realizar el commit,

63
00:03:16,260 --> 00:03:20,730
ya sea de forma manual con el método commit o de forma automática cuando se cierra la conexión.

64
00:03:20,820 --> 00:03:26,610
Bueno, un ejemplo, como siempre, acá tenemos un track con recursos, se fijan, obtenemos el connection

65
00:03:26,670 --> 00:03:32,700
con el que con el hecho, ya sea independiente de un punto de conexiones o sí de la clase Singleton

66
00:03:32,820 --> 00:03:34,680
y estamos conectando uno con entre manager.

67
00:03:34,680 --> 00:03:40,530
Conecté con Independiente, pero acá tenemos el objeto conexión y configuramos el set auto commit en

68
00:03:40,530 --> 00:03:40,920
fols.

69
00:03:40,980 --> 00:03:43,950
Justamente con este método Set auto Comitán lo dejamos en Ford.

70
00:03:44,040 --> 00:03:45,460
Recuerden por defecto es true.

71
00:03:45,630 --> 00:03:50,730
Entonces con eso ya podemos invocar ver sentencia dentro de un contexto todo como un solo bloque.

72
00:03:50,820 --> 00:03:54,720
Podemos hacer consulta o hacer una sentencia de insert o delete.

73
00:03:54,870 --> 00:03:57,510
En fin, incluso esta puede interactuar una con otra.

74
00:03:57,570 --> 00:04:01,290
Pueden guardar unos datos de una tabla guardar, insertar datos de otra tabla.

75
00:04:01,410 --> 00:04:04,340
A su vez podemos actualizar otra tabla con alguna llave.

76
00:04:04,350 --> 00:04:08,160
Se fijan y al final de este bloque, cuando se haya ejecutado todo.

77
00:04:08,310 --> 00:04:14,130
Realizamos el comité dentro del TROI y por supuesto, como es un Troi con recursos, se cierra de forma

78
00:04:14,130 --> 00:04:15,570
automática la conexión con el auto.

79
00:04:15,990 --> 00:04:20,460
Ahora, si no lo hacemos esta forma, sino solamente con el try de forma común y corriente, con el

80
00:04:20,460 --> 00:04:23,640
traje y todo, tenemos que cerrar de forma manual el.

81
00:04:24,060 --> 00:04:27,490
El conjunto cloud tipicamente en el bloque finali.

82
00:04:27,750 --> 00:04:27,930
Bien.

83
00:04:27,990 --> 00:04:30,120
Ahora, qué pasa si ocurre un error en el catch?

84
00:04:30,210 --> 00:04:35,400
Lo manejamos como siempre, pero además invocamos el rollback del guet con el hecho de que tu conexión

85
00:04:35,520 --> 00:04:39,960
ahora siempre portante tener en cuenta y esto es fundamental para el manejo transaccion.

86
00:04:40,050 --> 00:04:43,050
Siempre tienes que estar dentro de la misma conexión.

87
00:04:43,110 --> 00:04:43,950
Dreyman Instancia.

88
00:04:44,130 --> 00:04:49,380
Es decir, no puedo manejar un comit, un rollback, un manejo transaccion si estamos con diferente

89
00:04:49,380 --> 00:04:54,210
conexion a la Z tiene que ser una sola y en base a esta conexión vamos a ejecutar este bloque.

90
00:04:54,310 --> 00:04:59,550
Todas esta sentencias siempre en la misma conexión, ya sea si la conexión la obtenemos con un.

91
00:04:59,720 --> 00:05:00,500
Singleton.

92
00:05:00,560 --> 00:05:02,690
Como lo vimos, o con un pull de conexiones.

93
00:05:02,750 --> 00:05:08,630
Pero si lo obtenemos desde un pulpo, conexiones, siempre esa conexión que obtuvimos del pool bajo

94
00:05:08,630 --> 00:05:09,680
esa conexión.

95
00:05:09,800 --> 00:05:13,210
Realizamos la transacción y no pidiendo otra conexión del pull.

96
00:05:13,370 --> 00:05:14,810
Y sobre todo en el repositorio.

97
00:05:14,810 --> 00:05:18,980
Tampoco podemos cerrar la conexión del pool de conexiones, porque si una de esta sentencia de bloque

98
00:05:18,980 --> 00:05:25,010
cierra la conexión y después en otra sentencia solicitamos otra conexión del pool, obviamente van a

99
00:05:25,010 --> 00:05:31,090
ser conexiones tinta y no vamos a tener un bloque transaccional de siempre dentro de la misma conexión.

100
00:05:31,190 --> 00:05:34,100
Y después vamos a ver, hoy tendríamos que no cerrar la conexión.

101
00:05:34,220 --> 00:05:37,940
En cada método del repositorio repository no se cierra.

102
00:05:38,060 --> 00:05:43,430
Además, esta conexión se tiene que pasar al repositorio y se compartida por todos los métodos bajo

103
00:05:43,430 --> 00:05:44,510
la misma conexión.

104
00:05:44,630 --> 00:05:48,170
Misma transacción y tener una clase cérvix y dentro del service.

105
00:05:48,260 --> 00:05:54,950
Después vamos a ver, solicitar o pedir una conexión al pool y se la pasamos al repositorio, al repositorio

106
00:05:55,040 --> 00:05:56,330
o a los distintos repositorio.

107
00:05:56,480 --> 00:06:01,640
Podríamos tener un repositorio por tabla de nuestra base de datos y así cada repositorio podría interactuar

108
00:06:01,700 --> 00:06:02,310
uno con otro.

109
00:06:02,330 --> 00:06:05,540
Cada método uno con otro, siempre bajo la misma conexión.

110
00:06:05,720 --> 00:06:08,150
Bajo esta misma transacción es atómico.

111
00:06:08,240 --> 00:06:10,880
Es una unidad de trabajo y es por ÍLO.

112
00:06:11,090 --> 00:06:12,950
Bueno, eso sería la siguiente clase.

113
00:06:13,100 --> 00:06:14,480
Vamos a ver ejemplos.

114
00:06:14,630 --> 00:06:15,290
Nos vemos.
