UGD
| TRX//DB
🎓 UGD · Base de datos · Sistemas de Gestión

Transacciones ACID

Cómo las bases de datos garantizan la integridad absoluta de las operaciones de lectura y escritura en entornos concurrentes.

⚡ Atomicidad 🛡️ Consistencia 🔒 Aislamiento 💾 Durabilidad
🎓 INFORMACIÓN ACADÉMICA UGD
ALUMNO
Marquez Raul (Mat. 67594)
CARRERA / MATERIA
Ing. en Informática · Tec. de Bases de Datos
PROFESORES
Enrique Luis Barreyro & Suenaga Roberto
engine_wal.log
BEGIN TRANSACTION T1;
LOCK row_id=102 (EXCLUSIVE);
-- Leyendo saldo actual
READ saldo → $20,000;
UPDATE saldo SET = $10,000;
WRITE WAL_BUFFER (lsn=8921);
COMMIT T1; -- Durabilidad asegurada
01 · CONCEPTO CLAVE

¿Qué es una transacción?

Un conjunto de operaciones ejecutadas sobre una base de datos que se tratan como una única unidad atómica e indivisible de trabajo. O se completan todas las operaciones exitosamente, o el sistema vuelve al estado previo exacto.

PASO 01

Descontar $10.000 de tu cuenta

UPDATE cuentas SET saldo = saldo - 10000

➔
PASO 02

Entregar los billetes en el cajero

HARDWARE_DISPENSE_CASH()

⚠ Si el cajero se apaga o falla a mitad de camino, NINGUNO de los dos pasos surte efecto (Rollback).
02 · GARANTÍAS DEL MOTOR

Las 4 Propiedades ACID

El motor de base de datos aplica estrictamente estas cuatro reglas para garantizar que los datos nunca se corrompan.

A

Atomicidad

UNIDAD DE TODO O NADA

Todas las operaciones de la transacción se aplican de forma completa, o no se aplica ninguna. Si ocurre un fallo, todo cambio en memoria se deshace (Rollback).

💡 Ejemplo real: Reserva de pasaje con asiento — o se cobra la tarjeta y se emite el boleto juntos, o se deshace el cobro si no hay asiento disponible.
C

Consistencia

REGLAS E INTEGRIDAD

La base de datos pasa de un estado válido a otro estado válido, respetando todas las restricciones (claves foráneas, triggers, reglas de negocio y chequéos).

💡 Ejemplo real: En una transferencia entre dos cuentas, el total de dinero sumado entre ambas antes y después de la operación debe ser exactamente igual.
I

Aislamiento

CONCURRENCIA INDEPENDIENTE

Cada transacción se ejecuta como si fuera la única en el sistema. Las transacciones concurrentes no ven cambios intermedios sin confirmar de otras.

💡 Ejemplo real: Comprar la última entrada para un concierto al mismo tiempo que otro usuario — el bloqueo garantiza que solo uno concrete la orden.
D

Durabilidad

PERSISTENCIA PERMANENTE

Una vez confirmada la transacción (Commit), los cambios quedan grabados de forma permanente en el almacenamiento no volátil, resistiendo cortes de energía.

💡 Ejemplo real: Confirmación de transferencia bancaria — aunque el servidor colapse un segundo después, el saldo actualizado ya fue escrito en el disco/log.
03 · MÁQUINA DE ESTADOS

Ciclo de vida de una transacción

Etapas por las que transita una transacción desde su apertura hasta su cierre final.

01Activa
02Parcialmente confirmada
03Confirmada (Commit)
03bFallida (Abort)
04Terminada
Seleccioná un flujo para ver el avance por los estados.
04 · SIMULADOR EN VIVO

Ejemplo: Transferencia Bancaria

Observá cómo actúan la Atomicidad y Consistencia al transferir $10.000 entre la Cuenta A y la Cuenta B.

MONTO: $10.000
ESPERANDO ACCIÓN
CONSERVACIÓN DE CAPITAL: Suma Total = $25.000 (Regla de Consistencia)
[SYS] Motor listo. Esperando comando BEGIN TRANSACTION...
BEGIN TRANSACTION;
UPDATE cuentas SET saldo = saldo - 10000 WHERE id = 'A';
UPDATE cuentas SET saldo = saldo + 10000 WHERE id = 'B';
COMMIT;
05 · PROBLEMAS CONCURRENTES

Anomalías por falta de Aislamiento

Cuando múltiples transacciones acceden a las mismas filas de la base de datos simultáneamente sin control adecuado.

Stock Inicial: 10 unidades · Dos compras restan 1 al mismo tiempo · Resultado esperado: 8
TRANSACCIÓN T1 (Cliente #1)
TRANSACCIÓN T2 (Cliente #2)
-- Solución mediante Bloqueo Pesimista (FOR UPDATE):
SELECT stock FROM productos WHERE id = 482 FOR UPDATE;
MEDIDOR DE INVENTARIO REAL
10
Valor Esperado Correcto: 8

T2 lee un valor modificado por T1 que aún no ha sido confirmado (uncommitted). Si T1 aborta, T2 habrá operado con datos ficticios.

T1 T1 modifica el saldo de la cuenta a $50.000 (sin Commit).
T2 T2 lee el saldo ($50.000) y autoriza un préstamo en base a ese monto.
T1 T1 sufre un error y ejecuta ROLLBACK. El saldo real vuelve a $10.000.
ERR T2 procesó una aprobación basada en $50.000 que NUNCA EXISTIERON.
⚠ ANOMALÍA: T2 tomó decisiones operativas basadas en datos fantasma que fueron cancelados.

T1 realiza lecturas repetidas de un conjunto de datos mientras T2 altera dichos datos a mitad del proceso, generando reportes inconsistentes.

T1 T1 inicia un reporte contable leyendo los saldos del Estante 1 y Estante 2.
T2 T2 transfiere 50 cajas del Estante 3 al Estante 1 en simultáneo.
T1 T1 continúa la suma y llega al Estante 3 (donde ya se restaron las cajas).
ERR El reporte final de T1 arroja un total que NO coincide con la realidad física.
⚠ ANOMALÍA: El reporte contable mezcló datos del estado previo y posterior a la transferencia.
06 · SOLUCIONES DE ARQUITECTURA

Técnicas de Control de Concurrencia

Mecanismos utilizados por el DBMS para prevenir anomalías manteniendo el rendimiento óptimo.

🔒 Bloqueos (Locking)

Marcadores sobre filas o tablas. Compartido (Shared) permite lecturas simultáneas. Exclusivo (Exclusive) bloquea tanto lecturas como escrituras a otras transacciones.

Ejemplo: Cartel de "Reservado" en una mesa de restaurante — mientras esté activo, nadie más puede sentarse.

🚫 Interbloqueo (Deadlock)

Dos o más transacciones quedan bloqueadas mutuamente en un ciclo infinito de espera por recursos retenidos por la otra.

T1
T2
Presioná para simular la traba mutua.

⛺ Protocolo de Bloqueo en 2 Fases (2PL)

Garantiza la seriahilidad. Fase de Crecimiento (solo adquiere bloqueos) seguida de la Fase de Contracción (solo libera bloqueos).

Ejemplo: Armar un campamento — primero clavas todas las estacas y recién cuando terminas empiezas a guardarlas.

🎫 Marcas Temporales (Timestamps & MVCC)

Cada transacción recibe un identificador secuencial. MVCC (Multi-Version Concurrency Control) mantiene versiones de filas para leer sin bloquear.

Ejemplo: Número de turno en el banco — permite leer el estado previo sin detener a otros usuarios.
07 · RESILIENCIA Y LOGS

Recuperación ante fallos: WAL Log

Para cumplir con la Durabilidad (D), las bases de datos utilizan el patrón Write-Ahead Logging (WAL). Todo cambio se escribe primero en el archivo de log secuencial en disco antes de modificarse en las páginas de datos en RAM.

1. MEMORIA RAM

Buffer Pool

Modificaciones rápidas en caliente (Páginas sucias).

2. LOG SECUENCIAL

WAL Disk Log

Registro inmutable previo de cada operación (UNDO/REDO).

3. ARCHIVO DE DATOS

Data Files

Persistencia final en las tablas físicas.

08 · MATRIZ INTERACTIVA

Niveles de Aislamiento en SQL

Seleccioná cada nivel de aislamiento estándar ANSI/ISO SQL para ver dinámicamente qué anomalías están permitidas y cuáles son bloqueadas por el motor.

READ COMMITTED

Evita lecturas sucias asegurando que solo se lean datos confirmados con Commit. Es el nivel predeterminado en la mayoría de DBMS (PostgreSQL, SQL Server, Oracle).

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
Lectura Sucia (Dirty Read)
Leer cambios no confirmados
🟢 PROTEGIDO
Lectura No Repetible (Non-Repeatable Read)
Cambios en filas leídas durante la TRX
🔴 PERMITIDO
Lectura Fantasma (Phantom Read)
Nuevas filas insertadas por otra TRX
🔴 PERMITIDO
09 · CONTROL INTERACTIVO

Savepoints: Rollback Parcial

Los Savepoints permiten definir puntos de restauración intermedios en una transacción sin necesidad de abortar todo el trabajo previo.

1. BEGIN TRANSACTION [ACTIVA]
2. UPDATE clientes SET saldo = 5000 OK
🚩 3. SAVEPOINT punto_seguro; SAVEPOINT CREADO
4. UPDATE inventario SET stock = -10 (ERROR DE VALIDACIÓN) FALLO
SAVEPOINT punto_seguro;
-- Si el paso siguiente falla:
ROLLBACK TO SAVEPOINT punto_seguro;
COMMIT; -- Se guardan los pasos anteriores al savepoint!