Bien, continuemos con un nuevo tema relacionado JS La transacciones es un concepto bien simple, se
trata de ejecutar varias sentencias, operaciones, pero como si fueran una sola.
Toda junta y si alguna de esta llega a fallar, la idea es que no se ejecute o no se realice ninguna.
Es decir, que vuelva al estado anterior, que tenía la base.
Dato que no modifique nada.
Simplemente acá no pasó nada.
Claro, porque muchas veces cuando están ejecutando un grupo de sentencias que están relacionadas unas
con otra y por alguna razón una falla lanza un error.
Bueno, qué pasa?
Van a que los datos inconsistente en las tablas.
Algunos datos van a quedar, pero los datos de otra tabla no van a quedar por el error, se fijan.
Entonces queda en un estado inconsistente.
Entonces, en ese caso necesitamos mecanismos que se ejecutan.
En el fondo se ejecutan todas o ninguna y en caso de falla, devolver a su estado original.
Y eso todo.
Le enviamos una definición poco más formal.
Entonces, una transacción.
Es un conjunto.
Operaciones, sentencias sobre la base.
Dato que se deben ejecutar como una unidad de trabajo.
Un solo bloque como si fuera una sola.
Veámoslo.
Concepto que hay detrás.
Muy importante tener claro que si alguna llega a fallar en su ejecución de este bloque, cualquier sentencia
podemos dar marcha atrás, volver con un rollback y justamente se realiza un rollback.
Una llamada para que todo el bloque en ejecución que se está ejecutando vuelva a la original y todos
los cambios que se habían hecho no surjan efecto, se reviertan.
Y justamente cuando ocurre un error lo manejamos en el catch manejo excepciones y dentro del catch invocamos
el rollback.
Se fijan?
Pero si todo sale bien, todo el bloque se ejecuta de forma correcta.
No hay ningún problema.
Perfecto.
Realizamos un commit aplicando los cambios sobre la tabla que tan relacionada a este bloque trabajo.
Entonces lo que hace el commit justamente es aplicar los cambios o guarda los cambios de todo el bloque
ejecutado.
Bueno, pero para implementar transacciones necesitamos seguir algunos pasos.
Por ejemplo, cambiar la propiedad que es un atributo.
El auto commit de la conexión a la auto por defecto es true.
Lo tenemos que cambiar a fols.
Porque por defecto siempre acá que se ejecuta una sentencia automáticamente se hace un commit automáticamente
then true.
Entonces lo que vemos en fols.
Para que podamos manipular el commit de forma manual.
Entonces, si todo sale bien en las sentencias del bloque, realizamos el commit para guardar los cambios
en la Ayato, pero no solamente de una sentencia, sino de este conjunto dentro bloque.
Recuerden, es una unidad, trajo un conjunto y siempre la idea es que la transacción esté asociada
a un solo hilo.
El problema que tenemos multiusuario o múltiplo y todos trabajan sobre la misma transacción sería un
caos, no cierto?
Claro, tiene que ser individual.
Por eso se le llama una unidad de trabajo.
Es un punto importante.
Entonces los dos primeros paso es el auto commit en fours.
Luego, si todo sale bien, realizamos un commit invocando el método commit del objeto connection.
Ahora, si falla dentro del catch en el manejo de exepciones, realizamos o ejecutamos el método rollback
para revertir los cambios al estado original que tenían las tablas de ese conjunto o bloqueÃ se fijan.
Entonces invocamos el método rollback para regresar atrás.
Y otro tema importante el auto commit es tan fols.
Y en ninguna parte de nuestro código invocamos el método commit del objeto connection del objeto conexión.
Cuando cerramos la conexión de la Ayato o cuando se cierre de forma automática con el auto Closs de
forma automática también se va a realizar commit entonces siempre sí o si se va a realizar el commit,
ya sea de forma manual con el método commit o de forma automática cuando se cierra la conexión.
Bueno, un ejemplo, como siempre, acá tenemos un track con recursos, se fijan, obtenemos el connection
con el que con el hecho, ya sea independiente de un punto de conexiones o sí de la clase Singleton
y estamos conectando uno con entre manager.
Conecté con Independiente, pero acá tenemos el objeto conexión y configuramos el set auto commit en
fols.
Justamente con este método Set auto Comitán lo dejamos en Ford.
Recuerden por defecto es true.
Entonces con eso ya podemos invocar ver sentencia dentro de un contexto todo como un solo bloque.
Podemos hacer consulta o hacer una sentencia de insert o delete.
En fin, incluso esta puede interactuar una con otra.
Pueden guardar unos datos de una tabla guardar, insertar datos de otra tabla.
A su vez podemos actualizar otra tabla con alguna llave.
Se fijan y al final de este bloque, cuando se haya ejecutado todo.
Realizamos el comité dentro del TROI y por supuesto, como es un Troi con recursos, se cierra de forma
automática la conexión con el auto.
Ahora, si no lo hacemos esta forma, sino solamente con el try de forma común y corriente, con el
traje y todo, tenemos que cerrar de forma manual el.
El conjunto cloud tipicamente en el bloque finali.
Bien.
Ahora, qué pasa si ocurre un error en el catch?
Lo manejamos como siempre, pero además invocamos el rollback del guet con el hecho de que tu conexión
ahora siempre portante tener en cuenta y esto es fundamental para el manejo transaccion.
Siempre tienes que estar dentro de la misma conexión.
Dreyman Instancia.
Es decir, no puedo manejar un comit, un rollback, un manejo transaccion si estamos con diferente
conexion a la Z tiene que ser una sola y en base a esta conexión vamos a ejecutar este bloque.
Todas esta sentencias siempre en la misma conexión, ya sea si la conexión la obtenemos con un.
Singleton.
Como lo vimos, o con un pull de conexiones.
Pero si lo obtenemos desde un pulpo, conexiones, siempre esa conexión que obtuvimos del pool bajo
esa conexión.
Realizamos la transacción y no pidiendo otra conexión del pull.
Y sobre todo en el repositorio.
Tampoco podemos cerrar la conexión del pool de conexiones, porque si una de esta sentencia de bloque
cierra la conexión y después en otra sentencia solicitamos otra conexión del pool, obviamente van a
ser conexiones tinta y no vamos a tener un bloque transaccional de siempre dentro de la misma conexión.
Y después vamos a ver, hoy tendríamos que no cerrar la conexión.
En cada método del repositorio repository no se cierra.
Además, esta conexión se tiene que pasar al repositorio y se compartida por todos los métodos bajo
la misma conexión.
Misma transacción y tener una clase cérvix y dentro del service.
Después vamos a ver, solicitar o pedir una conexión al pool y se la pasamos al repositorio, al repositorio
o a los distintos repositorio.
Podríamos tener un repositorio por tabla de nuestra base de datos y así cada repositorio podría interactuar
uno con otro.
Cada método uno con otro, siempre bajo la misma conexión.
Bajo esta misma transacción es atómico.
Es una unidad de trabajo y es por ÍLO.
Bueno, eso sería la siguiente clase.
Vamos a ver ejemplos.
Nos vemos.