Mover 300 rupias de Asha a Ben requiere dos actualizaciones: restar de una cuenta y agregar a la otra. Si el sistema falla entre ellos, el dinero desaparece. Las transacciones SQL existen para hacer esto imposible, al tratar ambos pasos como una sola unidad.

En esta guía analizamos confirmaciones, reversiones y fallas en una tabla de cuentas pequeñas. Ejecutamos esos ejemplos en SQLite y los saldos que se muestran provienen de esa ejecución. Los comandos básicos son similares en todas las bases de datos, pero el comportamiento de bloqueo y aislamiento varía mucho, por lo que le indicamos dónde consultar la documentación de su propia base de datos.

¿Qué es una transacción?

Una transacción es una secuencia de una o más sentencias SQL que la base de datos trata como una única operación lógica. Aquí está nuestra tabla:

CREATE TABLE accounts (
  id INT PRIMARY KEY,
  owner TEXT,
  balance INT CHECK (balance >= 0)
);

INSERT INTO accounts VALUES (1, 'Asha', 1000), (2, 'Ben', 200);

La restricción CHECK es una regla según la cual un saldo nunca puede bajar de cero, que usaremos más adelante. Tenga en cuenta que la sintaxis para iniciar una transacción varía: SQLite y PostgreSQL aceptan BEGIN, MySQL también tiene START TRANSACTION y SQL Server usa BEGIN TRANSACTION.

Fuera de una transacción explícita, la mayoría de las bases de datos utilizan autocommit, donde cada declaración se guarda tan pronto como finaliza. Oracle es una excepción notable, porque una sesión allí permanece en una transacción hasta que usted se compromete.

COMPROMISO: hacerlo permanente

BEGIN;
UPDATE accounts SET balance = balance - 300 WHERE id = 1;
UPDATE accounts SET balance = balance + 300 WHERE id = 2;
COMMIT;

-- Asha | 700
-- Ben  | 500

Hasta que se ejecute COMMIT, los cambios son provisionales. Una vez que regresa exitosamente, la base de datos garantiza que están guardados. El total en ambas cuentas se mantuvo en 1200, que es el objetivo del ejercicio.

ROLLBACK: cancelar todo

ROLLBACK deshace todo desde que comenzó la transacción:

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
SELECT owner, balance FROM accounts;
-- Asha | 600   (visible inside this transaction)
-- Ben  | 500

ROLLBACK;
SELECT owner, balance FROM accounts;
-- Asha | 700   (back to where it was)
-- Ben  | 500

También se produce una reversión automáticamente si la conexión se interrumpe o el servidor falla antes de realizar la confirmación, por lo que una transacción a medio terminar no sobrevive.

Cuando una declaración falla

He aquí un caso más realista. Asha intenta enviar 5000, que la cuenta no contiene. El crédito a Ben se ejecuta primero y luego el débito infringe la regla CHECK:

BEGIN;
UPDATE accounts SET balance = balance + 5000 WHERE id = 2;
UPDATE accounts SET balance = balance - 5000 WHERE id = 1;
-- error: CHECK constraint failed: balance >= 0

ROLLBACK;

-- Asha | 700
-- Ben  | 500

Sin la transacción, Ben se habría quedado con los 5000 y los libros estarían equivocados. Tenga en cuenta un detalle importante: una declaración fallida no siempre cancela la transacción por sí sola. En SQLite y MySQL, por ejemplo, las declaraciones anteriores pueden permanecer pendientes, por lo que su código debe emitir la reversión. En cambio, PostgreSQL marca toda la transacción como cancelada y rechaza más declaraciones hasta que usted retroceda.

En el código de la aplicación, siempre empareje la transacción con el manejo de errores. Aquí está la idea en Python, y nuestra guía para el manejo de excepciones de Python explica la sintaxis:

try:
    conn.execute("BEGIN")
    conn.execute(debit_sql, values)
    conn.execute(credit_sql, values)
    conn.execute("COMMIT")
except Exception:
    conn.execute("ROLLBACK")
    raise

Puntos de guardado

Un punto de guardado marca una posición dentro de una transacción, por lo que solo puedes deshacer parte del trabajo:

BEGIN;
UPDATE accounts SET balance = balance - 50 WHERE id = 1;
SAVEPOINT bonus;
UPDATE accounts SET balance = balance + 999 WHERE id = 2;
ROLLBACK TO bonus;
UPDATE accounts SET balance = balance + 50 WHERE id = 2;
COMMIT;

-- Asha | 650
-- Ben  | 550

El bono 999 se deshizo, mientras que el resto de la transacción continuó y se comprometió. Esto es útil para pasos opcionales en un proceso largo.

Propiedades ácidas explicadas

La coherencia suele malinterpretarse. La base de datos aplica solo las reglas que usted declara, como restricciones y claves externas. No impedirá que su código transfiera la cantidad incorrecta. La durabilidad generalmente se logra con un registro de escritura anticipada, donde los cambios se registran de forma segura en el disco antes de que se confirme la confirmación.

¿Qué sucede con las transacciones concurrentes?

Abrimos dos conexiones a un archivo SQLite. El primero inició una transacción y actualizó una fila del 1 al 2, sin comprometerse aún. Esto es lo que vio la segunda conexión:

Connection B reads:   1                     -- no uncommitted data
Connection B writes:  database is locked    -- it has to wait
(A commits)
Connection B reads:   2                     -- now it sees the change

SQLite permite sólo un escritor a la vez, lo cual es más simple que las bases de datos del servidor, donde muchas transacciones pueden escribir diferentes filas simultáneamente. Pero el principio es el mismo: otras sesiones no deberían ver cambios no confirmados en la configuración normal, y las escrituras conflictivas tienen que esperar. En nuestra prueba, configuramos la segunda conexión para que se cerrara inmediatamente en lugar de esperar, por lo que el error apareció de inmediato.

Leer anomalías

Cuando las transacciones se superponen, pueden ocurrir ciertos problemas. El estándar SQL los define en términos de lo que puede observar una transacción:

Otro problema es la actualización perdida. Dos sesiones leen un saldo de 100, cada una suma 10 y cada una escribe 110. Una actualización efectivamente desapareció, cuando la respuesta debería ser 120.

Niveles de aislamiento de SQL

Los niveles de aislamiento le permiten cambiar el rigor por la simultaneidad. Esto es lo que permite el estándar SQL en cada nivel:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

La sintaxis y el comportamiento exactos dependen de su base de datos. Los valores predeterminados también difieren: PostgreSQL y SQL Server usan lectura confirmada, mientras que InnoDB de MySQL usa lectura repetible. Algunas bases de datos ofrecen garantías más estrictas que las que exige la norma, o tratan un nivel como otro. En PostgreSQL, por ejemplo, la lectura no confirmada se comporta como lectura confirmada. Lea siempre la documentación de su base de datos antes de confiar en un comportamiento específico.

Puntos muertos

Un punto muerto ocurre cuando dos transacciones tienen cada una un bloqueo que la otra necesita. La transacción A bloquea la fila 1 y quiere la fila 2, mientras que la transacción B bloquea la fila 2 y quiere la fila 1. Ninguna puede continuar.

Bases de datos como PostgreSQL, MySQL y SQL Server detectan esto y cancelan una transacción con un error. Ese es un comportamiento normal y su aplicación debe estar preparada para ello. Para reducir los puntos muertos, actualice siempre las filas en un orden coherente, como por ejemplo el ID de cuenta más bajo primero, mantenga las transacciones breves y vuelva a intentarlo cuando se elija a una como víctima.

Mejores prácticas

• Mantenga las transacciones cortas. Las largas mantienen bloqueos y bloquean a otros usuarios.
• Nunca espere a que haya un usuario o una API lenta dentro de una transacción. Haga ese trabajo antes de comenzar o después.
• Manejar siempre los errores. Cada ruta debe terminar en una confirmación o una reversión.
• Agregue restricciones. Le dan a la base de datos reglas reales que debe aplicar. Un buen diseño de mesa también ayuda.
• Utilice buenos índices. Las búsquedas más rápidas significan que los bloqueos se mantienen durante menos tiempo.
• Tenga cuidado con los reintentos. Vuelva a intentarlo en caso de interbloqueo, pero asegúrese de que una operación no se pueda aplicar dos veces.
• Pruebe la simultaneidad a propósito. Muchos de estos errores aparecen solo bajo carga, por lo que las pruebas de integración básicas por sí solas pueden no revelarlos.

Conclusión

Las transacciones convierten varios pasos riesgosos en una operación segura, y ACID describe las garantías que la hacen confiable. Siempre que una acción empresarial afecte a más de una fila o tabla, pregúntese qué pasaría si se detuviera a mitad de camino. Si la respuesta le preocupa, envuélvala en una transacción. Para practicar, abra dos sesiones en una base de datos local e intente producir las anomalías usted mismo.

Preguntas frecuentes

sigue aprendiendo