Nuestros desarrolladores estrellas agotaron sus reservas de café, en su búsqueda todo el tiempo por la resolución, hasta que Isabella halló el resultado en GitLab así que en este momento la compartimos aquí.
Solución:
En general, interbloqueo significa que dos o más entidades están bloqueando algunas fuentes, y ninguna de ellas puede finalizar, porque están bloqueando las fuentes de forma cíclica.
Un ejemplo: digamos que tengo la tabla A y la tabla B, necesito hacer una actualización en A y luego en B y decido bloquear ambas en el momento del uso (este es un comportamiento realmente estúpido, pero cumple su propósito ahora ). En el mismo momento, otra persona hace lo mismo en orden opuesto: primero bloquea B, luego bloquea A.
Cronológicamente, esto sucede:
proc1: Bloquear A
proc2: Bloqueo B
proc1: Bloqueo B – comienza a esperar hasta que proc2 suelte B
proc2: Lock A – comienza a esperar hasta que proc1 suelta A
Ninguno de los dos terminará jamás. Eso es un punto muerto. En la práctica, esto generalmente da como resultado errores de tiempo de espera, ya que no se desea que ninguna consulta se cuelgue para siempre, y el sistema subyacente (por ejemplo, la base de datos) eliminará las consultas que no finalicen a tiempo.
Un ejemplo del mundo real de un punto muerto es cuando cierra su casa keys en tu coche y tu coche keys en su casa.
¿Qué es un punto muerto?
Un interbloqueo ocurre cuando dos transacciones simultáneas no pueden avanzar porque cada una espera a que la otra libere un bloqueo, como se ilustra en el siguiente diagrama.
Debido a que ambas transacciones se encuentran en la fase de adquisición de bloqueo, ninguna libera un bloqueo antes de adquirir la siguiente.
Recuperarse de una situación de estancamiento
Si está utilizando un algoritmo de control de simultaneidad que se basa en bloqueos, siempre existe el riesgo de que se ejecute en una situación de punto muerto. Los interbloqueos pueden ocurrir en cualquier entorno de concurrencia, no solo en un sistema de base de datos.
Por ejemplo, un programa de subprocesos múltiples puede bloquearse si dos o más subprocesos están esperando bloqueos que se adquirieron previamente para que ningún subproceso pueda progresar. Si esto sucede en una aplicación Java, la JVM no puede simplemente forzar a un Thread a detener su ejecución y liberar sus bloqueos.
Incluso si el Thread clase expone un stop , ese método ha sido obsoleto desde Java 1.1 porque puede hacer que los objetos se dejen en un estado inconsistente después de que se detenga un hilo. En cambio, Java define un interrupt , que actúa como una pista, ya que un hilo que se interrumpe puede simplemente ignorar la interrupción y continuar su ejecución.
Por esta razón, una aplicación Java no puede recuperarse de una situación de interbloqueo, y es responsabilidad del desarrollador de la aplicación ordenar las solicitudes de adquisición de bloqueo de tal manera que nunca se produzcan interbloqueos.
Sin embargo, un sistema de base de datos no puede hacer cumplir una determinada orden de adquisición de cerraduras, ya que es imposible prever qué otras cerraduras querrá adquirir más una determinada transacción. Mantener el orden de bloqueo se convierte en responsabilidad de la capa de acceso a datos, y la base de datos solo puede ayudar a recuperarse de una situación de bloqueo.
El motor de la base de datos ejecuta un proceso separado que escanea el gráfico de conflicto actual en busca de ciclos de bloqueo-espera (que son causados por puntos muertos). Cuando se detecta un ciclo, el motor de la base de datos selecciona una transacción y la aborta, lo que hace que se liberen sus bloqueos, de modo que la otra transacción pueda avanzar.
A diferencia de la JVM, una transacción de base de datos está diseñada como una unidad atómica de trabajo. Por lo tanto, una reversión deja la base de datos en un estado coherente.
Prioridad de interbloqueo
Si bien la base de datos elige revertir una de las dos transacciones bloqueadas, no siempre es posible predecir cuál se revertirá. Como regla general, la base de datos puede optar por revertir la transacción con un costo de reversión menor.
Oráculo
Según la documentación de Oracle, la transacción que detectó el interbloqueo es aquella cuya declaración se revertirá.
servidor SQL
SQL Server le permite controlar qué transacción es más probable que se revierta durante una situación de interbloqueo a través del DEADLOCK_PRIORITY variable de sesión.
El DEADLOCK_PRIORITY La sesión puede aceptar cualquier número entero entre -10 y 10, o valores predefinidos como LOW (-5), NORMAL (0) o HIGH (5).
En caso de un interbloqueo, la transacción actual se revertirá, a menos que las otras transacciones tengan un valor de prioridad de interbloqueo menor. Si ambas transacciones tienen el mismo valor de prioridad, SQL Server revierte la transacción con el menor costo de reversión.
PostgreSQL
Como se explica en la documentación, PostgreSQL no garantiza qué transacción se revertirá.
MySQL
MySQL intenta revertir la transacción que modificó el número de registros de permisos, ya que liberar menos bloqueos es menos costoso.
El punto muerto es lo que sucede cuando dos personas necesitan varios recursos para ejecutarse y cada una de las personas bloquea algunos de los recursos. Esto lleva al hecho de que A no puede ejecutar sin algo que B tiene y viceversa.
Digamos que tengo la Persona A y la Persona B. Ambas necesitan obtener dos filas para ejecutarse (Fila1 y Fila2).
- La persona A bloquea Row1 e intenta obtener Row2.
- La persona B bloquea Row2 e intenta obtener Row1.
La persona A no puede ejecutarse porque necesita Row2, la persona B no puede ejecutarse porque necesita Row1. Ninguna persona podrá ejecutar nunca porque está bloqueando lo que la otra necesita y viceversa.
Una forma razonablemente simple de reducir el punto muerto es en todas sus transacciones complejas, debe realizar las operaciones en el mismo orden. En otras palabras, acceda a Table1 y luego a Table2 en el mismo orden. Esto ayudará a reducir el número de interbloqueos que se producen.