Durante cinco módulos hemos mirado el esquema de BiblioRed como se mira un plano: sobre la mesa, quieto, con tiempo para discutir si esa columna sobra o si esa clave ajena falta. El plano ya está bien. Las tablas están normalizadas, las restricciones escritas y las cuatro desnormalizaciones justificadas por escrito.

Esta mañana el plano se ha convertido en un edificio. El sistema ha entrado en producción en las cuatro sucursales de Vallmar y, con él, ha entrado el mundo real: hay dos personas en el mostrador de la sucursal Centro registrando préstamos a la vez, hay un socio pagando una multa con tarjeta mientras el servidor decide apagarse, y hay una consulta que en el portátil de desarrollo tardaba 30 milisegundos y aquí tarda catorce segundos.

Este módulo trata de todo eso. Y empieza por la pieza sobre la que descansa el resto: la transacción.

Una transacción es la respuesta de las bases de datos a una pregunta incómoda: ¿qué pasa si una operación se interrumpe por la mitad? No es una pregunta teórica. El servidor se apaga, el proceso muere, la red se corta, la aplicación lanza una excepción, el operario cierra la ventana. La única pregunta relevante no es si va a ocurrir, sino qué queda en la base de datos cuando ocurre. Y la respuesta que da una base de datos transaccional es tan simple como radical: queda todo, o no queda nada.

En esta lección veremos qué es una transacción y por qué existe, cómo se controla desde SQL, cómo se comporta cuando algo falla, y qué significan de verdad las cuatro letras de ACID —con especial detenimiento en la D de durabilidad y en el mecanismo que la hace posible, el registro de escritura anticipada o WAL, que es el mismo mecanismo que reaparecerá en la lección 06-04 cuando hablemos de copias de seguridad.

1. El problema: registrar un préstamo son tres operaciones
2. Qué es una transacción
3. Control de transacciones en SQL: BEGIN, COMMIT, ROLLBACK
4. El modo autoconfirmación: cada instrucción suelta ya es una transacción
5. Puntos de guardado: SAVEPOINT, ROLLBACK TO y RELEASE
6. El ciclo de vida de una transacción
7. Atomicidad: todo o nada
8. Consistencia: de un estado válido a otro válido
9. Aislamiento: enunciado aquí, desarrollado en 06-02
10. Durabilidad y el registro de escritura anticipada (WAL)
11. Puntos de control y recuperación tras una caída
12. El coste de la durabilidad y los parámetros que la relajan
13. Errores dentro de una transacción: el comportamiento de PostgreSQL
14. Transacciones y DDL
15. Buenas prácticas al escribir transacciones
16. Fuera de PostgreSQL: SQLite y MongoDB

Empecemos por el caso más común de BiblioRed. Marta Alsina (socia 14) se acerca al mostrador de la sucursal Centro con el ejemplar EJ-3081 de "El mapa del tiempo". Tenía una reserva pendiente sobre ese material. La persona del mostrador pulsa "Prestar".

Lo que la aplicación tiene que hacer en la base de datos son tres operaciones distintas:

Tres instrucciones. Cada una, por separado, es correcta. Y sin embargo el conjunto es una bomba, porque hay dos momentos en los que el mundo puede detenerse:

Ninguno de estos estados intermedios es un estado válido de la biblioteca. No existe una biblioteca en la que un libro esté prestado y disponible al mismo tiempo. Existe en la base de datos porque hemos escrito tres instrucciones donde el negocio tiene un solo hecho: "Marta se ha llevado el ejemplar EJ-3081".

Fíjate en que ninguna restricción del módulo 4 nos salva de esto. Un CHECK comprueba una fila; una clave ajena comprueba una referencia. Ninguna de las dos puede expresar "estas tres instrucciones van juntas". Necesitamos otra herramienta, de otra naturaleza: una que no hable de datos, sino de tiempo.

Definición. Una transacción es una secuencia de operaciones sobre la base de datos que el gestor trata como una sola unidad indivisible de trabajo: o se aplican todas sus operaciones, o no se aplica ninguna.

Tres consecuencias que conviene tener claras desde el principio:

• La transacción es una unidad lógica, no técnica. Su tamaño lo decide el negocio, no el motor. "Registrar un préstamo" es una transacción porque en la biblioteca es un acto único. Que sean tres UPDATE o siete es irrelevante.
• La frontera la marca quien escribe el código. El gestor no puede adivinar que esos tres UPDATE van juntos. Alguien tiene que decírselo, y ese alguien eres tú.
• Una transacción no es solo "un grupo de instrucciones". Es un grupo de instrucciones con cuatro garantías asociadas —las propiedades ACID— que el gestor se compromete a cumplir aunque se corte la luz.

El acrónimo ACID lo acuñaron Theo Härder y Andreas Reuter en 1983, formalizando ideas que Jim Gray venía desarrollando desde los años setenta en IBM. Recordarás del recorrido histórico de 01-03 que este es exactamente el periodo en que las bases de datos relacionales pasaron de prototipo de laboratorio a sistema de producción bancario: sin transacciones fiables, ese salto no habría sido posible.

La respuesta a las cuatro, en un gestor transaccional, es no. Las veremos una a una a partir del apartado 7. Antes hay que saber escribirlas.

El vocabulario es corto y no ha cambiado en cuarenta años:

START TRANSACTION es la forma del estándar SQL; BEGIN es la forma corta que PostgreSQL admite y que se usa en la práctica. Son equivalentes.

El préstamo de Marta, escrito correctamente:

Resultado esperado:

Y si algo va mal en medio —la aplicación detecta que el ejemplar ya estaba prestado, o el socio está dado de baja— basta con cambiar la última línea:

Después del ROLLBACK la base de datos está exactamente como estaba antes del BEGIN. No hay préstamo, el ejemplar sigue disponible y la reserva sigue activa. No hay que "deshacer a mano" nada: deshacer es responsabilidad del gestor, y lo hace bien.

Esta es la primera de varias demostraciones que debes reproducir abriendo dos terminales con psql conectados a la misma base de datos. Llamaremos Sesión A y Sesión B a cada una. Ejecuta las instrucciones en el orden de la columna "momento": el orden importa, y ahí está toda la enseñanza.

Dos cosas que aprender aquí:

1. Dentro de la transacción, A ve sus propios cambios (t3). Es coherente: A está trabajando.
2. Fuera de la transacción, B no ve nada (t4) hasta que A confirme. Es la propiedad de aislamiento asomándose. Qué ve exactamente cada sesión, en qué momento y bajo qué reglas, es el contenido íntegro de la lección 06-02; aquí solo nos interesa constatar que el trabajo no confirmado es invisible para los demás.

Una pregunta razonable: si las transacciones se abren con BEGIN, ¿qué pasa con los cientos de INSERT sueltos que escribimos en los módulos 2 y 3, sin BEGIN a la vista? ¿Estaban desprotegidos?

No. Estaban dentro de una transacción, solo que implícita.

Autoconfirmación (autocommit). Cuando el cliente no ha abierto una transacción explícita, el gestor envuelve cada instrucción individual en su propia transacción, que se confirma automáticamente si la instrucción tiene éxito y se deshace si falla.

Es decir, esto:

se comporta internamente como esto:

Y tiene una consecuencia muy útil que suele pasar desapercibida: una única instrucción SQL ya es atómica. Si ese UPDATE afecta a 9.400 ejemplares y falla en el 9.399 porque uno viola un CHECK, no quedan 9.398 filas modificadas: no queda ninguna. El estándar exige exactamente esto, y todos los gestores serios lo cumplen.

Ese último punto tiene una medida concreta. Cargar 200.000 filas en prestamos fila a fila en autoconfirmación puede tardar varios minutos; las mismas 200.000 filas dentro de un solo BEGIN ... COMMIT tardan unos segundos. La diferencia no está en el INSERT, está en el COMMIT: cada confirmación obliga a sincronizar el registro con el disco, y eso lo veremos en el apartado 10.

No todos los clientes se comportan igual, y esta es una fuente inagotable de sorpresas:

El error clásico con psycopg es escribir un INSERT, no llamar a commit(), cerrar el programa y no encontrar la fila. No se ha perdido: se ha deshecho, que es justo lo que debe pasar con una transacción que nunca se confirmó.

Un ROLLBACK es un instrumento contundente: deshace la transacción entera. A veces se necesita algo más fino, y para eso están los puntos de guardado.

Punto de guardado (savepoint). Marca con nombre dentro de una transacción abierta que permite deshacer el trabajo posterior a esa marca sin abortar la transacción completa.

Las tres instrucciones:

La documentación suele presentarlos con ejemplos artificiales. Los dos usos reales son estos:

Uso 1: operaciones opcionales dentro de una operación obligatoria.

Al registrar la devolución de un préstamo vencido, BiblioRed intenta emitir la multa correspondiente. Si el cálculo de la multa falla —porque el tipo de multa no está configurado para ese material, por ejemplo—, la devolución debe registrarse igualmente: es intolerable que un socio no pueda devolver un libro porque el sistema de multas está mal configurado.

Resultado esperado en el camino feliz:

Y en el camino con fallo, tras el ROLLBACK TO SAVEPOINT antes_multa, el COMMIT final confirma la devolución sin la multa. Que es exactamente lo que la biblioteca quiere.

Uso 2: recuperarse de un error sin perder el trabajo.

Este es el uso decisivo en PostgreSQL, y se entiende mejor en el apartado 13: cuando una instrucción falla dentro de una transacción, PostgreSQL aborta la transacción entera y rechaza todo lo que venga después. Un punto de guardado es la única forma de sobrevivir a un error y continuar. De hecho, cuando un controlador ofrece "reintentar esta instrucción", casi siempre está poniendo un SAVEPOINT implícito antes de cada instrucción.

Los puntos de guardado no son gratis: cada uno consume recursos internos del gestor. Poner uno antes de cada instrucción en un bucle de 100.000 iteraciones degrada el rendimiento de forma perceptible. Úsalos donde hay una decisión real que tomar, no por sistema.

El comportamiento que hemos visto responde a un autómata muy sencillo, presente en cualquier libro de texto y en la implementación de cualquier gestor:

Los cinco estados, con su significado práctico:

Hay dos detalles que suelen pasarse por alto y que aquí importan mucho.

El primero: "parcialmente confirmada" no es un tecnicismo. Es el instante crítico. La aplicación ha pedido COMMIT, el gestor ha aplicado los cambios en memoria, pero todavía no ha recibido la confirmación del disco de que el registro está a salvo. Si la máquina cae en ese microsegundo, la transacción no se ha confirmado y se deshará al arrancar. Por eso el gestor no le responde "COMMIT" al cliente hasta estar seguro: la respuesta al cliente es la promesa de durabilidad.

El segundo: de "confirmada" no se sale. No existe "des-confirmar". Un ROLLBACK después de un COMMIT no deshace nada —abre una transacción vacía y la deshace—. Si necesitas revertir algo ya confirmado, tienes que escribir la operación inversa, o restaurar de una copia (lección 06-04). Esta irreversibilidad es una característica, no un defecto: es lo que permite construir encima.

Atomicidad. Una transacción es indivisible: o se aplican todas sus operaciones o no se aplica ninguna. No existe estado intermedio observable ni persistente.

Qué garantiza. Que las tres instrucciones del préstamo de Marta se comporten como una sola. Que no exista jamás en prestamos una fila sin su correspondiente ejemplares.estado = 'prestado'.

Qué falla si no está. Exactamente la tabla de estados intermedios del apartado 1: préstamos fantasma, ejemplares prestados que figuran disponibles, reservas huérfanas. Y lo peor es que estos fallos son silenciosos. No hay error, no hay traza, no hay excepción. Solo una biblioteca que un día descubre que su inventario no cuadra y no sabe desde cuándo.

Cómo la implementa el gestor. Con la información necesaria para deshacer. Antes de modificar un dato, el gestor registra en algún sitio lo suficiente para volver atrás:

• PostgreSQL no sobrescribe las filas: cada UPDATE crea una versión nueva de la fila y marca la vieja como obsoleta a partir de esa transacción. Deshacer es tan simple como marcar la transacción como abortada: las versiones nuevas dejan de ser visibles para todo el mundo y las viejas siguen ahí. Este mecanismo es el MVCC, y su tratamiento completo es de 06-02. La consecuencia interesante es que en PostgreSQL un ROLLBACK es más barato que un COMMIT, al contrario que en otros gestores.
• Oracle, MySQL/InnoDB usan un segmento de deshacer (undo): guardan la imagen anterior de cada fila modificada y, al deshacer, la reponen.

Ambos caminos llegan al mismo sitio. La diferencia práctica es que PostgreSQL paga después, limpiando las versiones muertas con VACUUM (06-02), y los otros pagan durante, manteniendo el segmento de deshacer.

Provoquemos un fallo a propósito en mitad de una transacción. Vamos a intentar prestar un ejemplar a un socio que no existe (el 9999), con la clave ajena de 02-06 haciendo su trabajo:

Resultado esperado:

El UPDATE había funcionado. La atomicidad lo ha borrado del mapa. El ejemplar sigue disponible, como debe ser.

Consistencia. Una transacción lleva la base de datos de un estado válido a otro estado válido. Si la base cumplía todas sus reglas antes de la transacción, las cumple después.

Qué garantiza. Que al confirmar, ninguna clave ajena apunta a la nada, ningún CHECK está violado, ningún UNIQUE está duplicado y ningún NOT NULL está vacío. Todo el catálogo de restricciones de 04-04 y la integridad referencial de 02-06 siguen en pie al otro lado del COMMIT.

Qué falla si no está. Datos que contradicen las reglas del negocio: multas asignadas a préstamos inexistentes, inscripciones a eventos borrados, ejemplares en sucursales que cerraron.

Cómo la implementa el gestor. Comprobando las restricciones. La mayoría se comprueban al ejecutar cada instrucción; algunas pueden diferirse al COMMIT si se declararon DEFERRABLE, lo que es imprescindible cuando dos tablas se referencian mutuamente:

Si al llegar al COMMIT alguna restricción diferida no se cumple, el COMMIT falla y la transacción se deshace entera. Es la consistencia haciendo su trabajo en el último segundo.

Conviene decirlo, porque el estudiante que lea sobre el tema se lo encontrará: hay un consenso amplio en que la "C" de ACID no está a la misma altura que las otras tres.

Las razones son estas:

Si multas.importe puede ser negativo porque nadie escribió el CHECK, la base de datos aceptará -50,00 € sin protestar y habrá sido perfectamente "consistente": no ha violado ninguna regla, porque esa regla no existía. La consistencia del gestor es consistencia respecto a las restricciones declaradas, no respecto al sentido común.

Además, la atomicidad y el aislamiento ya implican buena parte de lo que la C promete. Por eso hay quien dice, con razón, que ACID son "tres propiedades y una letra que quedaba bien en el acrónimo". La postura útil para un profesional es intermedia: la C es un recordatorio de que las reglas del negocio deben estar declaradas en el esquema para que la transacción pueda protegerlas. Ese es exactamente el argumento del apartado 21 de la lección 04-04 sobre qué reglas van en la base y cuáles en la aplicación.

Aislamiento. Cada transacción se ejecuta como si fuera la única del sistema. Los resultados de una transacción concurrente no interfieren con los de otra.

Qué garantiza. Que puedas razonar sobre tu transacción sin pensar en las otras once que se están ejecutando a la vez.

Qué falla si no está. Los dos mostradores de Centro prestan el mismo ejemplar EJ-3081 al mismo tiempo. Dos socios ocupan la misma última plaza del club de lectura. Un informe suma cifras de un instante y cifras de otro, y no cuadra con nada.

Cómo la implementa el gestor. Con bloqueos, con control multiversión (MVCC), o con una combinación de ambos.

Y aquí paramos deliberadamente. El aislamiento es, con diferencia, la más compleja de las cuatro propiedades: es la única que admite grados —el estándar SQL define cuatro niveles y cada uno permite unos fenómenos y prohíbe otros—, es la única en la que el gestor te deja elegir cuánta garantía quieres a cambio de cuánto rendimiento, y es la fuente de los errores más difíciles de reproducir de toda esta profesión.

Todo eso es el contenido íntegro de la lección 06-02: los fenómenos de concurrencia uno a uno con dos sesiones reproducibles, los cuatro niveles de aislamiento y su tabla canónica, los bloqueos compartidos y exclusivos, el MVCC de PostgreSQL, los interbloqueos y el bloqueo optimista frente al pesimista. Aquí nos basta con la definición y con saber que el aislamiento existe, que tiene niveles, y que el nivel por omisión de PostgreSQL —READ COMMITTED— no es el más estricto.

Durabilidad. Una vez que el gestor ha respondido COMMIT, los cambios sobreviven a cualquier fallo posterior: corte de luz, apagado del proceso, caída del sistema operativo.

Qué garantiza. Que cuando el mostrador ve "Préstamo registrado", el préstamo existe. Aunque el edificio se quede sin luz medio segundo después.

Qué falla si no está. Que la biblioteca crea que ha cobrado una multa que no consta. Y, sobre todo, que nadie sepa cuáles de las operaciones de la última hora sobrevivieron y cuáles no.

Cómo se implementa es la parte interesante, y merece la pena entenderla porque explica muchas cosas del comportamiento de PostgreSQL, incluido el rendimiento.

Recuerda el gestor de buffers de la lección 01-04. La base de datos no lee ni escribe directamente en disco: mantiene en memoria una caché de páginas (en PostgreSQL, shared_buffers). Cuando un UPDATE modifica una fila, lo que se modifica es la página en memoria. Esa página queda marcada como sucia (modificada y no escrita a disco) y se escribirá "más tarde".

Esto es imprescindible para el rendimiento: la memoria es varios órdenes de magnitud más rápida que el disco, y agrupar escrituras evita miles de operaciones de entrada/salida.

Pero crea un problema evidente: si el COMMIT solo modifica memoria, un corte de luz se lleva por delante todo lo confirmado.

La solución ingenua sería escribir a disco todas las páginas modificadas en cada COMMIT. Es correcta, y es inaceptablemente lenta: las páginas modificadas están dispersas por el fichero de datos, y escribirlas obliga a saltos de cabezal (en disco mecánico) o a reescribir bloques enteros (en SSD). Una transacción que toca tres tablas escribiría en tres sitios lejanos del disco.

Registro de escritura anticipada (Write-Ahead Log, WAL). Antes de modificar una página de datos, el gestor escribe en un fichero de registro secuencial una anotación que describe el cambio. El registro se sincroniza a disco antes de confirmar la transacción; las páginas de datos pueden esperar.

La regla, enunciada de forma canónica, es de una simplicidad total:

Nunca se escribe un cambio en los ficheros de datos antes de haber escrito en disco el registro que lo describe.

¿Por qué es más rápido? Porque el registro es secuencial. Todas las anotaciones de todas las transacciones se añaden al final del mismo fichero, una detrás de otra. Escribir 4 KB al final de un fichero secuencial es la operación más barata que existe en cualquier sistema de almacenamiento. Escribir 4 KB en ocho sitios distintos del disco, no.

Así queda la secuencia real de un COMMIT:

Fíjate en el orden: la aplicación recibe el "COMMIT" en cuanto el registro está a salvo, no cuando los datos están escritos. Los datos pueden tardar minutos en llegar a su sitio definitivo. No importa: la información para reconstruirlos ya está en un sitio seguro.

En PostgreSQL el WAL vive en el directorio pg_wal/, en ficheros de 16 MB por omisión. Puedes verlo:

Y consultar la posición actual del registro (el LSN, Log Sequence Number, que es la dirección de un byte dentro del registro):

Ese número avanza con cada escritura. Es el reloj interno de la durabilidad, y volverá a aparecer en 06-04 cuando hablemos de recuperación a un instante concreto.

Si el registro creciera indefinidamente y hubiera que releerlo entero para recuperarse, arrancar una base de datos de dos años llevaría días. Por eso existen los puntos de control.

Punto de control (checkpoint). Operación periódica en la que el gestor escribe a disco todas las páginas sucias que hay en memoria y anota en el registro que, hasta ese punto, los ficheros de datos están al día.

Consecuencia: para recuperarse de una caída solo hay que leer el registro desde el último punto de control. Todo lo anterior ya está en los ficheros de datos.

Los parámetros que lo gobiernan en PostgreSQL:

Hay un compromiso claro: puntos de control frecuentes hacen la recuperación rápida pero cargan el disco durante el funcionamiento normal; puntos de control espaciados son más suaves en marcha pero alargan el arranque tras una caída.

Supongamos que a las 12:41 se va la luz en el centro de proceso de datos de Vallmar. El último punto de control fue a las 12:37. Entre las 12:37 y las 12:41 hubo 214 transacciones: 209 confirmadas y 5 abiertas en el momento del corte.

Al arrancar, PostgreSQL detecta que el cierre no fue limpio y ejecuta la recuperación, en dos fases:

Fase 1 — Rehacer (redo). Lee el registro desde el último punto de control y vuelve a aplicar todos los cambios anotados, tanto los de transacciones confirmadas como los de las que no lo estaban. Suena raro, y es deliberado: es más rápido reaplicarlo todo y limpiar después que ir decidiendo caso por caso.

Fase 2 — Deshacer (undo). Se descartan los efectos de las transacciones que no llegaron a confirmarse. En PostgreSQL esta fase es casi gratuita gracias al MVCC: las 5 transacciones abiertas simplemente nunca constan como confirmadas en el mapa de estados de transacción, así que sus versiones de fila son invisibles para todo el mundo y se limpiarán con VACUUM. En un gestor con segmento de deshacer, esta fase sí implica trabajo real de reposición.

El resultado tras la recuperación es exacto: las 209 confirmadas están; las 5 abiertas no dejaron rastro. Ni una a medias.

En el registro del servidor se ve así:

Ese "invalid record length" no es un error: es el gestor encontrando el final del registro válido, es decir, el instante exacto del corte. Léelo como "hasta aquí llegó la luz".

Este mecanismo —el registro, los puntos de control, rehacer y deshacer— es lo que en 01-04 llamamos gestor de transacciones y recuperación, trabajando codo con codo con el gestor de buffers. Ahora ya sabes qué hacen exactamente esas dos cajas del diagrama.

El fsync() del apartado 10 —la llamada al sistema que obliga al disco a confirmar que ha escrito de verdad— es la operación más cara de todo el ciclo. En un SSD de servidor decente ronda los 0,1-1 ms; en un disco mecánico, entre 5 y 15 ms. Ese tiempo es un techo duro: una base de datos no puede confirmar más transacciones por segundo de las que su disco puede sincronizar.

PostgreSQL ofrece un parámetro para relajarlo, y hay que entender exactamente qué se compra y qué se paga:

La ganancia es real y a veces espectacular: en cargas de muchas transacciones pequeñas, off puede multiplicar el número de transacciones por segundo. Pero la letra pequeña hay que decirla completa:

Con synchronous_commit = off puedes perder transacciones que el gestor ya te confirmó. La base de datos no queda corrupta —la atomicidad y la consistencia se mantienen: las transacciones perdidas se pierden enteras—, pero desaparecen operaciones que el usuario vio como completadas.

¿Es aceptable? Depende de la tabla:

Regla práctica: si perder los últimos segundos obliga a llamar a alguien por teléfono, no lo desactives.

Nota adicional: existe también el parámetro fsync = off. Ese sí desactiva la protección de raíz y puede dejar la base corrupta e irrecuperable ante un corte. Su único uso legítimo es una base de datos desechable de pruebas que se puede regenerar con un script. Nunca en producción, bajo ninguna circunstancia y por ningún motivo.

Este apartado explica uno de los mensajes de error más frecuentes —y peor entendidos— de PostgreSQL.

Cuando una instrucción falla dentro de una transacción explícita, PostgreSQL aborta la transacción entera. No la instrucción: la transacción. A partir de ese momento cualquier instrucción se rechaza hasta que se ejecute ROLLBACK (o ROLLBACK TO SAVEPOINT).

Dos cosas notables:

1. El SELECT —que es inofensivo— también se rechaza. La transacción está envenenada.
2. El COMMIT final ha respondido ROLLBACK. PostgreSQL no confirma una transacción abortada: la deshace. Es un comportamiento seguro y a la vez traicionero, porque una aplicación que solo comprueba "¿me han respondido al COMMIT?" creerá que todo fue bien.

La postura de PostgreSQL es la más estricta, y es defendible: si una instrucción de tu unidad de trabajo ha fallado, lo más probable es que tu unidad de trabajo ya no tenga sentido. Pero obliga a escribir el código de otra manera.

Si un error concreto es esperable y quieres sobrevivir a él, envuélvelo en un punto de guardado:

El alta de Nuria se ha conservado. La de Iván no. La transacción ha llegado viva al COMMIT.

Una característica de PostgreSQL que sorprende a quien viene de otros gestores: el DDL es transaccional. CREATE TABLE, ALTER TABLE, DROP TABLE, CREATE INDEX pueden ir dentro de una transacción y deshacerse con ROLLBACK.

Ni la columna ni la tabla existen. Esto tiene una consecuencia operativa enorme: una migración de esquema en PostgreSQL puede ser atómica. Si el paso 7 de 9 falla, el esquema vuelve intacto al estado inicial en lugar de quedarse a medio migrar, que es la peor situación posible en una madrugada de despliegue.

Las excepciones en PostgreSQL, que conviene conocer:

• CREATE DATABASE, DROP DATABASE, CREATE TABLESPACE no pueden ir en una transacción.
• CREATE INDEX CONCURRENTLY —el que no bloquea la tabla— tampoco: es precisamente su forma de no bloquear. Volverá en 06-03.
• VACUUM tampoco.

Y una advertencia importante: que el DDL sea transaccional no significa que sea gratis. Un ALTER TABLE toma un bloqueo fuerte sobre la tabla, y mientras la transacción esté abierta nadie más podrá usarla. Los bloqueos son el tema de 06-02.

Cuatro reglas que evitan la mayoría de los problemas de producción. Las tres primeras se resumen en una idea: una transacción abierta es un recurso caro que alguien más está esperando.

Una transacción abierta retiene bloqueos, impide que VACUUM limpie versiones muertas y consume una ranura de conexión. Cuanto más dure, más molesta.

Un DELETE de nueve millones de filas por lotes:

Cada ejecución es su propia transacción (autoconfirmación), corta, interrumpible y que no hincha el registro con nueve millones de anotaciones de golpe.

Es el error clásico del sistema de mostrador:

Ese FOR UPDATE mantiene bloqueada la fila del ejemplar durante cuarenta minutos, y cualquier otro mostrador que intente tocarlo se queda esperando. El patrón correcto es leer sin transacción, mostrar el diálogo, y abrir la transacción después de que el humano decida —comprobando entonces que nada haya cambiado—. Es exactamente el bloqueo optimista, que se ve en 06-02.

Como red de seguridad, PostgreSQL permite cortar a los descuidados:

Cualquier sesión que se quede más de 30 segundos con una transacción abierta sin hacer nada será desconectada. En producción es muy recomendable poner un valor razonable.

Dos problemas de naturaleza distinta:

• De rendimiento: la transacción dura lo que dure la red.
• De corrección, y este es el grave: la llamada externa no se deshace con ROLLBACK. Si el COMMIT falla después de haber cobrado, has cobrado y no consta. La transacción de base de datos no puede deshacer el mundo exterior.

El patrón correcto separa las dos cosas: una transacción registra la intención (pagos con estado iniciado), se hace la llamada externa fuera de toda transacción, y una segunda transacción registra el resultado. Con una referencia idempotente para poder reintentar sin cobrar dos veces —para eso está la columna pagos.referencia.

Una transacción puede fallar por causas transitorias: un interbloqueo, un fallo de serialización, una desconexión momentánea. Estos errores no significan que el código esté mal; significan que hay que volver a intentarlo. Una aplicación seria envuelve sus transacciones en un reintento con espera creciente y un número máximo de intentos. La mecánica concreta se ve en 06-02, donde aparecen los errores que se deben reintentar y los que no.

SQLite es plenamente ACID, lo cual sorprende a quien lo toma por "una base de datos de juguete". No lo es: es la base de datos más desplegada del mundo, y es transaccional de verdad.

Sus diferencias vienen de su naturaleza embebida (01-04):

Activar el modo WAL, que es lo primero que se hace en cualquier uso serio de SQLite:

El concepto es el mismo que en PostgreSQL —escribir primero el registro—, aplicado a un fichero local. La diferencia decisiva sigue siendo la granularidad del bloqueo: PostgreSQL bloquea filas; SQLite bloquea el fichero entero para escribir. Para BiblioRed, con cuatro mostradores escribiendo a la vez, SQLite sería una mala elección; para la aplicación de inventario que un bibliotecario lleva en una tableta y sincroniza al final del día, sería perfecta.

Retomando lo que vimos en 03-04:

La atomicidad a nivel de documento explica por qué el modelado documental de 03-03 empuja a agrupar en un documento lo que debe cambiar junto. Si el préstamo y el estado del ejemplar viven en el mismo documento, la operación es atómica sin transacción alguna.

Con documentos separados sí hace falta una transacción explícita:

Funciona, y es correcto. Pero en MongoDB una transacción multidocumento tiene un coste notablemente mayor que en PostgreSQL, y la comunidad la trata como la excepción, no como la herramienta habitual. El criterio de 03-04 sigue siendo válido: si tu dominio necesita transacciones multidocumento a todas horas, es una señal fuerte de que el modelo relacional encaja mejor con tu problema.

Creer que el ROLLBACK deshace lo confirmado. No existe. Una vez respondido el COMMIT, el único camino de vuelta es una operación compensatoria o una restauración desde copia (06-04). Escribe el código sabiendo que COMMIT es un punto de no retorno.

Confiar en el COMMIT sin comprobar la respuesta. Como vimos en el apartado 13, un COMMIT sobre una transacción abortada responde ROLLBACK sin lanzar excepción en algunos clientes. Comprueba siempre el resultado; no supongas.

Dejar la transacción abierta a la espera de un humano o de una red. Es el origen del 80 % de los problemas de bloqueo en producción. Configura idle_in_transaction_session_timeout y no lo dejes al criterio de nadie.

Meter todo el proceso nocturno en una sola transacción. Nueve horas de proceso en una transacción abierta impiden limpiar versiones muertas, hinchan la base y, si falla en la hora octava, se pierde todo. Divide por lotes con confirmación intermedia.

Olvidar commit() en el controlador. Con psycopg y con muchos ORM, si no confirmas, el trabajo se descarta al cerrar la conexión. Sin error, sin aviso, sin fila.

Usar synchronous_commit = off en tablas que representan dinero o inventario. La ganancia de rendimiento es real y la pérdida potencial también. Decídelo tabla por tabla, no globalmente, y déjalo escrito.

Tocar fsync = off alguna vez en producción. No hay ningún caso. Ninguno.

No poner un SAVEPOINT donde hay un error esperable. Si tu lógica tiene un "esto puede fallar y no pasa nada", en PostgreSQL necesita un punto de guardado. Sin él, el fallo se lleva por delante toda la transacción.

Consejo final: nombra las transacciones en el código. Un método registrarPrestamo() que abre y cierra la transacción entera, con el BEGIN y el COMMIT visibles en el mismo bloque de código, se lee y se audita. Un BEGIN en un sitio y un COMMIT tres capas más abajo es una fuente inagotable de transacciones olvidadas.

En BiblioRed, devolver un ejemplar implica: (a) poner fecha_devolucion en prestamos; (b) poner ejemplares.estado = 'disponible'; (c) si hay retraso, emitir una multa de 0,20 € por día en multas. La emisión de la multa es opcional: si falla, la devolución debe registrarse igualmente.

Escribe la transacción completa para el préstamo 88214 del socio 14 sobre el ejemplar 3081, cuya fecha_devolucion_prevista era 2026-07-15 y que se devuelve el 2026-08-02. Usa un punto de guardado donde corresponda y calcula el importe con SQL, no a mano.

Dada la siguiente secuencia, indica qué filas de socios existen al final y por qué. Supón que la sucursal 77 no existe y que las demás sí.

La concejalía de Vallmar quiere reducir el tiempo de respuesta del mostrador. Un técnico propone poner synchronous_commit = off en el fichero de configuración del servidor, para toda la base de datos. Argumenta con tres puntos concretos por qué esa decisión, tal como está formulada, es inaceptable, y propón una alternativa que conserve parte del beneficio.

Solución 1

Puntos clave de la solución:

• El INSERT ... SELECT con la condición AND p.fecha_devolucion > p.fecha_devolucion_prevista hace que la multa se emita solo si hay retraso, sin necesidad de lógica en la aplicación. Si no hay retraso, la respuesta es INSERT 0 0 y no pasa nada.
• El importe se calcula con la resta de fechas (18 días × 0,20 € = 3,60 €), leyendo del propio préstamo ya actualizado dentro de la misma transacción. Es correcto porque la transacción ve sus propios cambios.
• El punto de guardado permite que, si el INSERT falla —por ejemplo, porque un CHECK de multas rechaza un importe superior al máximo de la ordenanza—, la aplicación ejecute ROLLBACK TO SAVEPOINT antes_multa y confirme igualmente la devolución.
• El orden importa: primero prestamos, luego ejemplares, luego multas. Mantener siempre el mismo orden de acceso a las tablas previene interbloqueos (06-02).

Solución 2

Al final no existe ninguna de las cuatro filas. Recorrido paso a paso:

La trampa del ejercicio es doble. Primera: ROLLBACK TO s2 no aborta la transacción, la rescata —sin él, todo lo posterior habría fallado con current transaction is aborted—. Segunda: ROLLBACK TO s1 descarta B y D, que muchos dan por confirmadas porque "ya habían pasado". Un punto de guardado deshace todo lo posterior a la marca, incluidas las operaciones que tuvieron éxito.

Solución 3

Punto 1 — El alcance es global cuando el problema no lo es. Ponerlo en el fichero de configuración lo aplica a todas las transacciones, incluidas las de pagos y multas. La biblioteca aceptaría perder cobros confirmados a cambio de que el mostrador vaya más rápido. No es un intercambio que un servicio público pueda hacer, y desde luego no lo puede decidir un técnico en solitario.

Punto 2 — No se ha medido dónde está el problema. No hay ningún dato que diga que el tiempo de respuesta del mostrador se va en el fsync(). Es igual de probable —más, de hecho— que se vaya en una consulta sin índice (06-03), en el tiempo de red o en el propio interfaz. Cambiar un parámetro de durabilidad antes de haber medido es actuar sobre una hipótesis no verificada, y encima con la garantía de seguridad como moneda.

Punto 3 — El riesgo no está acotado ni comunicado. "Se pueden perder las últimas transacciones" es una afirmación que la concejalía debe conocer y aceptar por escrito, porque afecta a datos de ciudadanos y a cobros. Una decisión de este tipo no es técnica: es de riesgo operativo, y se documenta.

Alternativa razonable. Dejar synchronous_commit = on como configuración global y desactivarlo por transacción, solo en las operaciones donde perder unos segundos es tolerable:

Con SET LOCAL el efecto muere al terminar la transacción, así que no puede escaparse a otra operación por accidente. Y antes de eso: medir con EXPLAIN ANALYZE (06-03) dónde se va realmente el tiempo del mostrador, que casi nunca está donde se cree.

Esta lección ha cambiado el objeto de estudio. Hasta el módulo 5 mirábamos la estructura: qué tablas, qué columnas, qué restricciones. A partir de aquí miramos el comportamiento: qué ocurre cuando el sistema está en marcha y las cosas salen mal.

La transacción es la unidad con la que se razona sobre ese comportamiento. Hemos visto que registrar un préstamo en BiblioRed son tres instrucciones pero un solo hecho, y que quien decide dónde empieza y acaba una unidad de trabajo no es el gestor, sino quien escribe el código. Hemos visto el vocabulario completo —BEGIN, COMMIT, ROLLBACK, SAVEPOINT, ROLLBACK TO, RELEASE—, el modo de autoconfirmación que envuelve cada instrucción suelta en su propia transacción, y el ciclo de cinco estados por el que pasa toda transacción, con ese instante crítico de "parcialmente confirmada" en el que el gestor todavía no ha prometido nada.

De las cuatro propiedades ACID hemos desarrollado tres. La atomicidad, que borra los estados intermedios y hace que un ROLLBACK en PostgreSQL sea más barato que un COMMIT. La consistencia, que es la letra a medias —el gestor protege las reglas que le has declarado, y solo esas, lo que convierte cada CHECK y cada clave ajena del módulo 4 en parte de la garantía transaccional—. Y la durabilidad, que hemos abierto en canal: el registro de escritura anticipada que se sincroniza antes que los datos porque escribir secuencialmente es barato y escribir disperso no lo es; el punto de control que acota cuánto registro hay que releer; la recuperación en dos fases —rehacer todo desde el último punto de control, descartar después lo no confirmado— que devuelve la base exactamente al último COMMIT respondido; y el precio de todo ello, ese fsync() que pone un techo duro al número de transacciones por segundo y que synchronous_commit permite relajar a cambio de aceptar, por escrito, qué se está dispuesto a perder.

También hemos aprendido a convivir con el carácter estricto de PostgreSQL: una instrucción fallida aborta la transacción entera, y el punto de guardado es la única forma de sobrevivir a un error esperable. A cambio, PostgreSQL regala algo que otros gestores no tienen: DDL transaccional, y con él migraciones de esquema que o se aplican enteras o no dejan rastro.

Queda una letra sin desarrollar, y es la más difícil de las cuatro. El aislamiento lo hemos enunciado —cada transacción se comporta como si estuviera sola— y hemos visto asomarse su efecto en la demostración de dos terminales del apartado 3, donde la sesión B no veía nada de lo que la sesión A estaba haciendo. Pero no hemos dicho qué ocurre cuando las dos sesiones tocan la misma fila, ni qué ve exactamente cada una, ni qué pasa si las dos deciden a la vez que el ejemplar EJ-3081 está disponible y las dos lo prestan.

Eso es la lección 06-02, Concurrencia y Niveles de Aislamiento: los cuatro fenómenos clásicos —actualización perdida, lectura sucia, lectura no repetible, lectura fantasma— provocados uno a uno con dos terminales psql sobre los datos de BiblioRed; el sesgo de escritura, que sorprende incluso en niveles altos de aislamiento; los cuatro niveles del estándar SQL con la tabla de qué permite cada uno y qué hace realmente PostgreSQL; los bloqueos compartidos y exclusivos con SELECT ... FOR UPDATE; el control multiversión que hace que en PostgreSQL los lectores nunca bloqueen a los escritores, y el VACUUM que paga esa factura; los interbloqueos, con dos sesiones que se esperan mutuamente para siempre hasta que el gestor mata a una; y la solución final y completa al problema que ya está esperándonos en la agenda del club de lectura de la sucursal Norte: dos socios inscribiéndose en el mismo segundo a la última plaza libre.