Respuesta.

Historia de la pregunta

Con la aparición de bases de datos multiusuario, surgió el problema de limitar la modificación simultánea de los mismos datos. Esto llevó a la creación de varios mecanismos de bloqueo (gestión de bloqueos) que evitan cambios paralelos y ayudan a mantener la integridad de los datos.

Problema

Sin control de acceso, las operaciones simultáneas pueden provocar daños o pérdidas de datos: por ejemplo, dos transacciones actualizan al mismo tiempo una fila, y los cambios de una transacción se pierden. Bloqueos no lo suficientemente estrictos conducen a problemas de concurrencia (condiciones de carrera), mientras que un exceso lleva a la pérdida de rendimiento (interbloqueos, contención).

Solución

En las bases de datos modernas existen niveles de bloqueo (nivel de fila, nivel de página, nivel de tabla) y diferentes modos (compartido, exclusivo, actualización). El programador puede gestionar esto a través de configuraciones de aislamiento de transacciones y comandos de bloqueo explícitos (por ejemplo, SELECT ... FOR UPDATE).

Ejemplo de código:

-- Bloqueo de fila hasta el final de la transacción
BEGIN TRANSACTION;
SELECT * FROM users WHERE id = 1 FOR UPDATE;
UPDATE users SET name = 'New Name' WHERE id = 1;
COMMIT;

Características clave:

Granularidad del bloqueo (fila, página, tabla)
Bloqueos explícitos e implícitos (a través de transacciones e instrucciones especiales)
Influencia del nivel de aislamiento en el esquema de bloqueos

Preguntas capciosas.

¿Cuál es la diferencia entre un bloqueo de lectura (bloqueo compartido) y un bloqueo de escritura (bloqueo exclusivo)?

El bloqueo compartido permite a varias transacciones leer datos al mismo tiempo, pero no permite modificaciones. El bloqueo exclusivo permite que solo una transacción modifique datos, prohibiendo el acceso a todas las demás.

¿Puede un comando SELECT causar un bloqueo?

Normalmente, SELECT no causa bloqueos, pero si se utiliza SELECT ... FOR UPDATE o en un alto nivel de aislamiento (por ejemplo, SERIALIZABLE), la base de datos puede bloquear filas.

Ejemplo de código:

SELECT * FROM products WHERE id = 10 FOR UPDATE;

¿Los bloqueos siempre protegen contra "actualizaciones perdidas"?

No, si se elige incorrectamente el nivel de bloqueo o aislamiento, se puede obtener una "actualización perdida" — cuando los cambios de una transacción se pierden debido a otra. Es necesario elegir cuidadosamente los mecanismos de control de concurrencia.

Errores comunes y anti-patrones

Elección incorrecta del nivel de aislamiento (demasiado bajo o demasiado alto)
Insuficientes bloqueos explícitos en consultas críticas
Abuso de bloqueos globales (nivel de tabla) que conducen a caídas en el rendimiento
No liberar bloqueos debido a transacciones no concluidas

Ejemplo de la vida real

Caso negativo

En el departamento de análisis, dos programas actualizan simultáneamente el estado de los pedidos. Para acelerar, se estableció el nivel READ UNCOMMITTED, para no bloquear filas. Esto llevó a conflictos y "actualizaciones perdidas", parte de los datos se dañó.

Ventajas:

Buena velocidad al principio

Desventajas:

Pérdida/daño de datos clave
Dificultades para la recuperación

Caso positivo

En el departamento de ventas, se envolvieron los lugares críticos en TRANSACTION + SELECT ... FOR UPDATE. Se delimitaron las operaciones de lectura y actualización a nivel de fila.