Transacciones en base de datos

Las transacciones brindan una fiabilidad a las bases de datos. Si disponemos de una serie de consultas que deben ejecutarse en conjunto, con el uso de transacciones podemos tener la certeza de que nunca nos quedaremos a medio camino de su ejecución. En realizad se podría decir que las transacciones aportan una característica de “deshacer” a las aplicaciones de bases de datos.

Por ejemplo, si vamos a una entidad bancaria, y solicitamos una transferencia para pagar una compra realizada vía Internet, el proceso estaría formado por un conjunto de operaciones que deberán ser realizadas para que el proceso de pago tena éxito

• Comprobación de existencia, validez y operatividad de cuenta.
• Comprobación de si hay saldo en cuenta.
• Comprobación de datos de la cuenta destino.
• Retiro de dinero de nuestra cuenta.
• Abono de dinero en la cuenta de destino.

Dentro de este proceso hay 05 operaciones, las cuales deben tener éxito o fallar todas en conjunto.

Un tema importante y que esta relacionado con las transacciones es la gestión de la concurrencia y los bloqueos. En el el proceso de pago los 3 primeros pasos realmente no implican modificación alguna de datos, por lo que si fallan no dejarían la base de datos en un estado inconsistente, sin embargo ¿Qué pasaría si al mismo tiempo que se está realizando nuestra transferencia, entra en nuestra cuenta un cargo diferido que teníamos pendiente? Sería posible que de repente nos quedásemos sin saldo para realizar la operación actual.

Propiedades ACID

Una transacción para cumplir con su propósito, debe cumplir las siguientes características

• ATOMICIDAD: Las operaciones que componen una transacción deben considerarse como una sola.
• CONSISTENCIA: Una operación nunca deberá dejar datos inconsistentes.
• AISLAMIENTO: Los datos “sucios” deben estar aislados, y evitar que los usuarios utilicen información que aún no está confirmada o validada. (Para el proceso de pago planteado, ¿sigue siendo válido el saldo mientras realizo la operación?)
• DURABILIDAD: Una vez completada la transacción los datos actualizados ya serán permanentes y confirmados.

A estas propiedades se las suele conocer como propiedades ACID (de sus siglas en inglés: Atomicity, Consistency, Isolation y Durability).

Niveles de aislamiento

Los niveles de aislamiento que nos ofrecen las base de datos relacionales en general son:

• SERIALIZABLE: No se permitirá a otras transacciones la inserción, actualización o borrado de datos utilizados por nuestra transacción. Los bloquea mientras dura la misma.
• REPEATABLE READ: Garantiza que los datos leídos no podrán ser cambiados por otras transacciones, durante esa transacción.
• READ COMMITED: Una transacción no podrá ver los cambios de otras conexiones hasta que no hayan sido confirmados o descartados.
• READ UNCOMMITTED: No afectan los bloqueos producidos por otras conexiones a la lectura de datos.

Por regla general en los gestores de datos relacionales modernos disponen de tres tipos de transacciones según la forma de iniciarlas:

• De confirmación automática: El gestor de datos inicia una transacción automáticamente por cada operación que actualice datos. De este modo mantiene siempre la consistencia de la base de datos, aunque puede generar bloqueos.
• Implícitas: Cuando el gestor de datos comienza una transacción automáticamente cada vez que se produce una actualización de datos, pero el que dicha transacción se confirme o se deshaga, lo debe indicar el programador.
• Explícitas: son las que iniciamos nosotros “a mano” mediante instrucciones SQL, somos nosotros, los programadores, los que indicamos qué operaciones va a abarcar. Una transacción explícita se define de manera general con una instrucción que marca su inicio, y dos posibles instrucciones que marcan su final en función de si debe tener éxito o debe fracasar en bloque.

Cada sistema gestor de bases de datos tiene sus pequeñas particularidades, pero podemos escribir con un pseudo-código, la sintaxis de una transacción genérica:

BEGIN TRAN
      Operación 1...
      Si fallo: ROLLBACK TRAN 
       Operación 2....
       Si fallo: ROLLBACK TRAN...
      Operación N....      Si fallo: ROLLBACK TRAN
COMMIT TRAN

En siguientes entradas se detallará el manejo de transacciones, haciendo uso de los gestores de base de datos relacionales mas conocidos.

Referencias:

https://www.postgresql.org/docs/11/sql-start-transaction.html

https://dev.mysql.com/doc/refman/8.0/en/commit.html

https://docs.microsoft.com/en-us/sql/t-sql/language-elements/transactions-transact-sql

https://docs.oracle.com/cd/B19306_01/server.102/b14220/transact.htm