Espera tu turno
Para que nadie pise el trabajo de otro, las transacciones piden permiso antes de leer o escribir. A veces dos se esperan mutuamente para siempre. Al terminar sabrás detectarlo y resolverlo.
Primero, la idea completa
Mira el video entero o salta a la parte que quieras repasar. Después, cada idea tiene su propia escena para tocarla.
Cada quien a lo suyo, sin pisarse
En la lección anterior viste qué pasa cuando dos transacciones tocan los mismos datos sin coordinarse. La solución más común es la exclusión mutua: mientras una transacción usa un dato, ninguna otra puede modificarlo.
Se implementa con bloqueos. La idea es simple: antes de leer o escribir algo, la transacción le pide permiso al gestor de control de concurrencia. Si lo obtiene, “adquiere un bloqueo” sobre ese dato y puede trabajar con la certeza de que nadie se lo cambiará mientras lo tenga.
02 · Dos tipos de bloqueoCompartido para leer, exclusivo para escribir
- Compartido (S): si T1 tiene un bloqueo S sobre el dato Q, puede leer Q pero no escribirlo. Varias transacciones pueden tener S sobre el mismo dato al mismo tiempo: leer entre varios no daña a nadie.
- Exclusivo (X): si T1 tiene un bloqueo X sobre Q, puede leer y escribir Q. Nadie más puede tener ningún bloqueo sobre Q mientras tanto.
También se les llama bloqueos de lectura y de escritura. Si lo que pides no es compatible con lo que otro ya tiene, esperas hasta que lo suelte. Y lo suelta al llegar a su punto de sincronización: COMMIT o ROLLBACK.
T1 ya tiene un bloqueo sobre la cuenta Q. Elige cuál, y luego qué pide T2. ¿Se lo conceden o espera?
El interbloqueo
Los bloqueos traen su propio problema. T1 tiene la cuenta 1 y pide la 2; T2 tiene la 2 y pide la 1. Cada una espera a que la otra suelte, y ninguna puede soltar hasta terminar: esperarían para siempre. Eso es un interbloqueo o deadlock.
Puede involucrar a dos, tres o más transacciones: T0 espera a T1, T1 espera a T2… y la última espera a T0. Ninguna avanza.
Para detectarlo, el sistema dibuja el grafo de espera: una flecha de cada transacción hacia la que está esperando. Si hay un ciclo, hay interbloqueo. Entonces elige una víctima del ciclo, la deshace con ROLLBACK y libera sus bloqueos para que las demás sigan. La víctima no hizo nada malo; la aplicación recibe un error y normalmente la vuelve a intentar.
Tres transacciones. Toca una flecha para activar o quitar “espera a”. Busca el ciclo.
Dos estrategias
- Prevención: un protocolo que garantiza que el sistema nunca llegue a un interbloqueo, por ejemplo obligando a pedir los datos siempre en el mismo orden, o abortando a quien pediría esperar a una transacción más antigua. Conviene cuando los interbloqueos serían frecuentes.
- Detección y recuperación: se deja que ocurran, se buscan ciclos en el grafo de espera y se rompen eligiendo una víctima. Es más eficiente cuando son raros, y es lo que hacen la mayoría de los sistemas.
Ambas pueden obligar a retroceder transacciones. El retroceso puede ser parcial: basta con deshacer hasta el punto en que se obtuvo el bloqueo que causa el problema.
Si cada transacción adquiere todos sus bloqueos antes de soltar cualquiera (fase de crecimiento y fase de liberación), la ejecución es seriable. A eso se le llama bloqueo en dos fases. Si además los suelta todos juntos en el COMMIT, como en este simulador, se llama estricto.
Antes de leer la respuesta
En
REPEATABLE READ, cada lectura deja un bloqueo S hasta el COMMIT. Por eso dos transacciones que leen y luego escriben la misma cuenta son la receta perfecta para un interbloqueo.Tu turno: tres sesiones y un grafo de espera
Tres sesiones en REPEATABLE READ: cada lectura toma un bloqueo compartido y cada escritura, uno exclusivo, y todos se sueltan en el COMMIT o el ROLLBACK. En la tabla ves quién tiene qué bloqueo y quién está esperando; abajo, el grafo de espera se dibuja solo.
Comprueba lo que entendiste
Cada respuesta incorrecta explica por qué parece correcta y en qué falla.