¿Qué causa los bloqueos mutuos y cómo los previene?

Question

Accepted Answer

Un **deadlock** ocurre cuando dos (o más) transacciones cada una sostiene un bloqueo que la otra necesita, de modo que ninguna puede proceder — quedan atrapadas esperándose mutuamente indefinidamente. Las bases de datos detectan deadlocks y los resuelven **abortando una transacción** (la "víctima"), que debe reintentar. Entender las causas y la prevención es importante para aplicaciones concurrentes.

## Cómo ocurre un deadlock

```text
Transaction A: locks row 1, then wants row 2
Transaction B: locks row 2, then wants row 1
→ A waits for B (to release row 2), B waits for A (to release row 1) → DEADLOCK
  Neither can proceed; they're waiting on each other in a cycle.
```

```sql
-- Transaction A                    -- Transaction B (concurrent)
BEGIN;                              BEGIN;
UPDATE accounts SET .. WHERE id=1;  UPDATE accounts SET .. WHERE id=2;  -- each locks a row
UPDATE accounts SET .. WHERE id=2;  UPDATE accounts SET .. WHERE id=1;  -- each wants the OTHER's
-- → DEADLOCK: the database aborts one transaction
```

## Cómo las bases de datos manejan los deadlocks

```text
Databases DETECT deadlocks (find the cycle of waiting transactions) and resolve them
by ABORTING one transaction (the victim) with a deadlock error → it must RETRY.
→ Your application must handle the deadlock error and retry the transaction.
```

## Estrategias de prevención

```text
✓ CONSISTENT LOCK ORDERING — always acquire locks in the SAME order (e.g. always
  lock the lower account id first). This breaks the cycle → the #1 prevention technique.
✓ Keep transactions SHORT — hold locks for less time (less chance to overlap)
✓ Access tables/rows in a consistent order across all transactions
✓ Use lower isolation levels where appropriate (less locking)
✓ Avoid user interaction / long operations inside a transaction (holds locks too long)
✓ Handle deadlock errors with RETRY logic (deadlocks can't be fully eliminated)
```

La **prevención #1** es **orden consistente de bloqueos**: si todas las transacciones adquieren bloqueos en el mismo orden (por ejemplo, siempre el id más bajo primero), la espera circular no puede formarse.

## El patrón de reintento

```text
Since deadlocks can still happen, applications should catch the deadlock error and
RETRY the transaction (often a few times with a small delay). This is standard
resilience for concurrent database code.
```

## Por qué es importante

Los deadlocks son un problema importante de concurrencia en bases de datos — ocurren en cualquier aplicación con transacciones concurrentes que modifican datos superpuestos, y entenderlos es conocimiento valioso de nivel senior para construir sistemas concurrentes robustos.

Entender la **causa** — dos transacciones cada una sosteniendo un bloqueo que la otra necesita, creando una espera circular donde ninguna puede proceder — es la base.

Saber cómo las bases de datos **manejan** los deadlocks (detectando el ciclo y abortando una transacción como víctima, que debe reintentar) es importante porque significa que tu **aplicación debe manejar errores de deadlock con lógica de reintento** — los deadlocks no pueden eliminarse completamente, por lo que el código concurrente resiliente detecta el error de deadlock e reintenta (un patrón estándar e importante).

Las **estrategias de prevención** son el conocimiento práctico clave, especialmente la técnica #1: **orden consistente de bloqueos** (siempre adquiriendo bloqueos en el mismo orden en todas las transacciones, lo que rompe la condición de espera circular que causa deadlocks) — junto con mantener transacciones cortas (sosteniendo bloqueos brevemente), accediendo a recursos en un orden consistente, y evitando operaciones largas dentro de transacciones.

Ya que los deadlocks causan problemas reales (transacciones fallidas, errores, rendimiento degradado) en aplicaciones de base de datos concurrentes, y ya que entender su causa (esperas circulares de bloqueos), prevención (especialmente orden consistente de bloqueos y transacciones cortas), y la necesidad de lógica de reintento es lo que te permite construir sistemas concurrentes robustos, entender los deadlocks es conocimiento valioso de nivel senior para cualquier aplicación con acceso significativo concurrente a base de datos — una preocupación operacional frecuentemente relevante y un tema común de entrevista avanzada demostrando comprensión de concurrencia de base de datos y resiliencia.