Todo o nada: las transacciones

Trabajas en una aplicación de pagos. Elena envía 300 € a Raúl.

El programa resta 300 € de la cuenta de Elena. Justo después, el servidor se reinicia.

Elena ya no tiene ese dinero y Raúl no lo ha recibido. Para un banco, ese es el peor fallo posible. Las transacciones existen para que no ocurra.

Mover dinero exige dos cambios: restar en una cuenta y sumar en la otra.

Entre los dos cambios hay un momento en que el dinero no está en ningún sitio. Si algo falla justo ahí, el total de las cuentas ya no cuadra.

La tabla de abajo enseña ese momento. Nadie debería verlo nunca.

BEGIN abre una transacción. Los cambios que siguen quedan pendientes.

COMMIT los confirma todos a la vez. Hasta ese momento, nadie más ve los cambios a medias.

Si el servidor se cae antes del COMMIT, la base de datos descarta lo pendiente al arrancar. Nunca se queda con la mitad.

-- Elena paga 300 euros a Raúl.
BEGIN;
UPDATE accounts SET balance = balance - 300 WHERE id = 1;
UPDATE accounts SET balance = balance + 300 WHERE id = 2;
COMMIT;

-- Los dos saldos han cambiado y el total sigue siendo 600.
SELECT owner, balance FROM accounts;
SELECT SUM(balance) AS total FROM accounts;

A veces la aplicación ve un problema a mitad: no hay saldo, o la cuenta de destino está bloqueada.

Entonces envía ROLLBACK. La base de datos deshace todos los cambios desde BEGIN.

Las cuentas vuelven a estar como antes, como si la transferencia no hubiera empezado.

-- La misma transferencia, pero algo va mal a mitad.
BEGIN;
UPDATE accounts SET balance = balance - 300 WHERE id = 1;
-- Aquí la aplicación detecta un error y lo anula todo.
ROLLBACK;

-- Elena sigue teniendo 500 euros.
SELECT owner, balance FROM accounts;

-- Cambia ROLLBACK por COMMIT y vuelve a ejecutar. ¿Adónde van los 300 euros?