Interbloqueo en DBMS

En una base de datos, un interbloqueo es una situación no deseada en la que dos o más transacciones esperan indefinidamente una a la otra para abandonar los bloqueos. Se dice que Deadlock es una de las complicaciones más temidas en DBMS, ya que detiene todo el sistema. 

Ejemplo: comprendamos el concepto de interbloqueo con un ejemplo: 
supongamos que la transacción T1 mantiene un bloqueo en algunas filas de la tabla Estudiantes y necesita actualizar algunas filas en la tabla Calificaciones. Simultáneamente, la transacción T2 mantiene bloqueos en esas mismas filas (que T1 necesita actualizar) en la tabla de calificaciones, pero necesita actualizar las filas en la tabla de estudiantes que tiene la transacción T1 . 

Ahora, surge el principal problema. La transacción T1 esperará a que la transacción T2 renuncie al bloqueo y, de manera similar, la transacción T2 esperará a que la transacción T1 renuncie al bloqueo. Como consecuencia, toda la actividad se detiene y permanece paralizada para siempre a menos que el DBMS detecte el interbloqueo y cancele una de las transacciones. 

Prevención de interbloqueos: 
cuando una base de datos se atasca en un interbloqueo, siempre es mejor evitar el interbloqueo en lugar de reiniciar o cancelar la base de datos. El método de prevención de interbloqueos es adecuado para bases de datos más pequeñas, mientras que el método de prevención de interbloqueos es adecuado para bases de datos más grandes. 
Un método para evitar interbloqueos es usar una lógica coherente con la aplicación. En el ejemplo anterior, las Transacciones que acceden a Estudiantes y Calificaciones siempre deben acceder a las tablas en el mismo orden. De esta forma, en el escenario descrito anteriormente, la Transacción T1 simplemente espera a que la transacción T2 libere el bloqueo de Calificaciones antes de que comience. Cuando la transacción T2 libera el bloqueo, la transacción T1 puede proceder libremente. 
Otro método para evitar interbloqueos es aplicar tanto el mecanismo de bloqueo de nivel de fila como el nivel de aislamiento de LECTURA COMPROMETIDA. Sin embargo, no garantiza la eliminación completa de interbloqueos. 

Detección de interbloqueo: 
cuando una transacción espera indefinidamente para obtener un bloqueo, el sistema de administración de la base de datos debe detectar si la transacción está involucrada en un interbloqueo o no. 

Wait-for-graph es uno de los métodos para detectar la situación de interbloqueo. Este método es adecuado para bases de datos más pequeñas. En este método, se dibuja un gráfico basado en la transacción y su bloqueo en el recurso. Si el gráfico creado tiene un circuito cerrado o un ciclo, entonces hay un interbloqueo. 
Para el escenario mencionado anteriormente, el gráfico Wait-For se dibuja a continuación 

Prevención de interbloqueos: 
para una base de datos grande, el método de prevención de interbloqueos es adecuado. Se puede evitar un interbloqueo si los recursos se asignan de tal manera que nunca se produzca un interbloqueo. El DBMS analiza las operaciones si pueden crear una situación de interbloqueo o no. Si lo hacen, nunca se permite que se ejecute esa transacción. 

El mecanismo de prevención de interbloqueo propone dos esquemas: 

• Esquema Wait-Die: 
  en este esquema, si una transacción solicita un recurso que está bloqueado por otra transacción, entonces el DBMS simplemente verifica la marca de tiempo de ambas transacciones y permite que la transacción anterior espere hasta que el recurso esté disponible para su ejecución. 
  Supongamos que hay dos transacciones T1 y T2, y que la marca de tiempo de cualquier transacción T sea TS (T). Ahora, si hay un bloqueo en T2 por alguna otra transacción y T1 solicita recursos en poder de T2, DBMS realiza las siguientes acciones: 

  Comprueba si TS (T1) < TS (T2): si T1 es la transacción más antigua y T2 ha retenido algún recurso, permite que T1 espere hasta que el recurso esté disponible para su ejecución. Eso significa que si una transacción más joven ha bloqueado algún recurso y una transacción anterior lo está esperando, entonces se permite que una transacción anterior lo espere hasta que esté disponible. Si T1 es una transacción más antigua y ha retenido algún recurso con ella y si T2 la está esperando, entonces T2 se cancela y se reinicia más tarde con un retraso aleatorio pero con la misma marca de tiempo. es decir, si la transacción más antigua ha retenido algún recurso y la transacción más joven espera el recurso, entonces la transacción más joven se cancela y se reinicia con un retraso de un minuto con la misma marca de tiempo. 
  Este esquema permite que la transacción más antigua espere pero mata a la más joven. 
   

• Esquema de espera herida: 
  en este esquema, si una transacción anterior solicita un recurso en poder de una transacción más joven, entonces una transacción anterior obliga a una transacción más joven a eliminar la transacción y liberar el recurso. La transacción más joven se reinicia con un minuto de retraso pero con la misma marca de tiempo. Si la transacción más joven solicita un recurso que está en manos de una más antigua, se le pide a la transacción más joven que espere hasta que la más antigua lo libere. 

   

En la siguiente tabla se enumeran las diferencias entre los esquemas de prevención del esquema Wait – Die y Wound -Wait:

Espera – Muere	Herida -Espera
Se basa en una técnica no preventiva.	Se basa en una técnica preventiva.
En esto, las transacciones más antiguas deben esperar a que la más joven libere sus elementos de datos.	En esto, las transacciones más antiguas nunca esperan a las transacciones más jóvenes.
El número de abortos y retrocesos es mayor en estas técnicas.	En esto, el número de cancelaciones y retrocesos es menor.

Referencias: diferencia de  
docs.oracle  
entre wait-die y herida-wait 
Libro: fundamentos de los sistemas de bases de datos de Navathe