Transacciones y ACID
Mapa conceptual
Qué es una transacción
Una transacción es una secuencia de lecturas y escrituras tratada como una unidad lógica de trabajo. Empieza con un inicio explícito y termina con un commit (hacer permanentes los cambios) o un rollback (deshacerlos). Todo lo que hay entre esos dos puntos debe verse, para el resto del sistema, como instantáneo e indivisible.
Atomicidad
La A de ACID: la transacción es atómica, no se puede quedar a medias. Si algo falla en mitad del proceso, la base deshace todos los cambios ya aplicados y vuelve al estado previo. No existen transacciones «parcialmente completadas».
Consistencia
La C: una transacción válida lleva la base de un estado consistente a otro, respetando todas las restricciones (claves, checks, integridad referencial). Si una operación rompería la consistencia, la transacción se rechaza. Es la responsabilidad compartida entre esquema y aplicación.
Aislamiento
La I: transacciones concurrentes no deben pisarse. Cada una debe comportarse como si estuviera sola, aunque se ejecuten a la vez. Los grados de aislamiento deciden cuánto se permite interferir, y cada nivel tiene su equilibrio entre corrección y rendimiento.
Durabilidad
La D: una vez confirmada una transacción, sus efectos sobreviven a cortes de energía o caídas. Se logra escribiendo el registro de transacciones en almacenamiento persistente antes de dar el commit por bueno.
Anomalías de concurrencia
- Sucia: leer datos de una transacción aún no confirmada que podría rehacerse.
- No repetible: leer dos veces el mismo dato y hallar valores distintos por un cambio ajeno.
- Fantasma: una consulta repetida ve aparecer o desaparecer filas por inserciones de otros.
- Pérdida de actualización: dos transacciones sobrescriben la misma fila y una se pierde.
Niveles de aislamiento
El estándar define niveles de READ UNCOMMITTED a SERIALIZABLE. Cuanto más laxo, más concurrencia y más riesgo de anomalías; cuanto más estricto, más corrección y menos rendimiento. Elegir nivel es una decisión consciente sobre qué anomalías puedes tolerar.
Bloqueos
El mecanismo clásico para el aislamiento es bloquear datos: un bloqueo exclusivo para escribir y uno compartido para leer. Así se evita que dos transacciones choquen sobre la misma fila. El precio es la espera y el riesgo de interbloqueo.
Interbloqueo
Dos transacciones se bloquean mutuamente: cada una espera un recurso que la otra tiene. La base lo detecta y mata a una de ellas (la víctima), que se rehace y reintenta. Buena práctica: adquirir bloqueos en un orden consistente para minimizarlo.
El registro de transacciones
Antes de tocar los datos, cada cambio se anota en un log persistente. Si hay caída, el registro permite rehacer lo confirmado y deshacer lo incompleto (recuperación). Es la pieza que sostiene atomicidad y durabilidad.
Commit en dos fases
Cuando una transacción reparte varias bases o servicios, se coordina con un protocolo en dos fases: preparar a todos y, solo si todos aceptan, confirmar. Resuelve el dilema de dejar un participante con el cambio hecho y otro no, a costa de latencia y de un coordinador que debe sobrevivir.
Commit frente a rollback
- BEGIN abre la transacción y marca el punto de retorno.
- Las operaciones acumulan cambios aún invisibles o provisionales.
- COMMIT los hace permanentes y libera bloqueos.
- ROLLBACK los descarta y devuelve el estado inicial.
| Propiedad | Garantiza | Se rompe si |
|---|---|---|
| Atomicidad | todo o nada | un fallo deja cambios a medias |
| Consistencia | restricciones válidas | la aplicación fuerza un dato inválido |
| Aislamiento | no interferencia | transacciones concurrentes se pisotean |
| Durabilidad | persistencia del commit | se pierde el registro ante un corte |
Una transferencia descuenta de una cuenta y, antes de abonar a la otra, el sistema se cae. ¿Qué propiedad ACID asegura que el descuento se revierta?
Aislamiento en la práctica
Muchos motores por defecto no llegan a SERIALIZABLE, y aplicaciones que lo asumen sufren lecturas no repetibles. Conocer el nivel real de tu base evita sorpresas: lo que parece un bug es a veces el nivel de aislamiento permitido.
Lecturas y MVCC
El control de concurrencia por versiones (MVCC) permite leer una instantánea consistente sin bloquear a los escritores: cada transacción ve los datos tal como estaban a su inicio. Así se evitan esperas y lecturas fantasma a costa de guardar versiones.
Transacciones largas
Mantener una transacción abierta mucho tiempo retiene bloqueos y hace crecer el log. La regla es mantenerlas cortas: no dejar pasos de aplicación ni llamadas de red dentro de una transacción activa.
ACID frente a BASE
En sistemas distribuidos masivos se relaja ACID por BASE (básicamente disponible, eventual), sacrificando aislamiento inmediato por disponibilidad y escalado. Elegir uno u otro depende de si la corrección fuerte o la respuesta rápida manda en el negocio.
Errores frecuentes
- Asumir el aislamiento máximo sin comprobar el nivel real del motor.
- Dejar trabajo de aplicación (llamadas externas, bucles) dentro de una transacción abierta.
- No manejar el reintento cuando una transacción es abortada por interbloqueo.
Una vez confirmado un commit, sus cambios sobreviven a un corte de energía.
Por qué importa en datos
Los procesos de carga, las transformaciones y los pipelines que escriben en bases transaccionales dependen de estas garantías: una carga que falla a medias debe poder rehacerse sin dejar tablas inconsistentes. Pensar en transacciones protege la calidad del dato.
Ordena el ciclo de vida de una transacción:
Abrir
Operar
Decidir
Cerrar
Wikipedia
Definición formal de las propiedades ACID y su historia.
Explica con un ejemplo de reserva de asiento de avión por qué dos reservas simultáneas del mismo asiento requieren aislamiento. ¿Qué anomalía aparece sin él?
Documentación PostgreSQL
Referencia oficial de SQL y bases de datos.