Transacciones

¿Qué es una transacción?

Una transacción es un conjunto de operaciones sobre la base de datos que se tratan como si fueran una sola. Lo importante no es que sean varias, sino la regla que las une:

O se hacen todas, o no se hace ninguna.

No existe un estado intermedio. Si en el medio de una transacción algo falla —un error, un corte de luz, un disco lleno— la base de datos vuelve al estado en el que estaba antes de empezar, como si nada hubiera pasado.

El caso que lo explica todo

El ejemplo clásico es una transferencia bancaria. Transferir dinero de una cuenta a otra son, en realidad, dos operaciones distintas:

1. Restarle 10.000 al saldo de la cuenta de origen.
2. Sumarle 10.000 al saldo de la cuenta de destino.

Las dos tienen que ocurrir. Si se hace la primera y algo falla antes de la segunda, el dinero desaparece: salió de una cuenta y nunca llegó a la otra. La base de datos sigue siendo válida técnicamente —los dos saldos son números correctos— pero la realidad ya no coincide con lo que dice la base.

El problema que resuelve

Sin transacciones, cada operación se guarda apenas se ejecuta. Eso funciona bien mientras nada falle, y falla mal cuando algo falla. Y las fallas no son hipotéticas: son cortes de luz, errores de red, programas que se cierran, discos que se llenan.

Qué tiene que poder hacer el gestor

Para que esto funcione, el gestor de base de datos tiene que poder resolver tres situaciones distintas, y las tres son responsabilidad de la transacción:

• Deshacer lo hecho a medias. Si la segunda operación falla, hay que poder revertir la primera. Es la parte más difícil, porque la primera operación ya se ejecutó.
• Sobrevivir a un corte. Si se corta la luz en el medio, al volver a encender el sistema tiene que poder saber que había una transacción a medias y terminarla de deshacer.
• Evitar que otro vea el estado intermedio. Mientras la transferencia está a medio hacer, existe un instante en el que el dinero no está en ninguna de las dos cuentas. Ninguna otra consulta debería poder ver ese instante.

Esas tres necesidades son exactamente las propiedades que se describen en la sección siguiente.

Las propiedades ACID

Toda transacción tiene que cumplir cuatro propiedades, que se conocen por sus iniciales en inglés: ACID. No son una recomendación: son las garantías que el gestor se compromete a dar.

Confirmar o deshacer

Una transacción se escribe con tres instrucciones, y todas las bases de datos relacionales usan variantes muy parecidas:

• Iniciar la transacción: a partir de acá, nada se guarda de forma definitiva.
• Confirmar (COMMIT): lo hecho se hace permanente.
• Deshacer (ROLLBACK): lo hecho se revierte por completo.

START TRANSACTION;

UPDATE cuentas SET saldo = saldo - 10000 WHERE id = 1;
UPDATE cuentas SET saldo = saldo + 10000 WHERE id = 2;

COMMIT;

Y si algo sale mal en el medio, se deshace todo con una sola instrucción:

START TRANSACTION;

UPDATE cuentas SET saldo = saldo - 10000 WHERE id = 1;

-- el saldo quedaria negativo, la operacion no es valida
ROLLBACK;

-- La cuenta 1 queda con el saldo que tenia antes.
-- La transaccion no dejo ningun rastro.

Por qué el ROLLBACK no se escribe a mano

En un programa real no se decide "deshacer" a mano: el manejador de la transacción lo hace solo. El programa indica dónde empieza y dónde termina, y si en el medio se produce cualquier error —una restricción que no se cumple, un dato que no existe, un corte de conexión— la transacción se deshace automáticamente. Por eso un sistema bancario no puede quedar a medias por un error inesperado: no depende de que el programador se acuerde de revertir.

Varias transacciones a la vez

En un sistema real, cientos de usuarios trabajan al mismo tiempo. Esto trae un problema que no aparece cuando se trabaja solo, y que vale la pena entender con un ejemplo.

La cuenta con 1.000 pesos

Una cuenta tiene 1.000 pesos y hay dos personas retirando 800 al mismo tiempo, cada una desde su computadora. Si las dos operaciones se ejecutan sin ningún control, puede pasar esto:

1. La transacción A lee el saldo: 1.000. Le parece suficiente.
2. La transacción B lee el mismo saldo: 1.000. También le parece suficiente.
3. A resta 800 y guarda: el saldo queda en 200.
4. B resta 800 sobre lo que había leído (1.000) y guarda: el saldo queda en 200.

Se retiraron 1.600 pesos de una cuenta que tenía 1.000, y el saldo final dice 200. La base de datos está equivocada porque las dos transacciones se pisaron sin darse cuenta.

Cómo lo resuelve el aislamiento

Es la propiedad I de ACID. El gestor hace que las transacciones que tocan los mismos datos se turnen: mientras una está trabajando sobre esa cuenta, la otra espera. Así cada una ve un estado coherente y el resultado final es el correcto.

Cuidar el aislamiento tiene un costo: esperar significa perder velocidad. Por eso los gestores permiten regular cuánto aislamiento aplicar: en un sistema bancario se exige el máximo, y en un tablero de estadísticas que solo lee se puede aflojar bastante sin riesgo.

Resumen