Un interbloqueo devuelve el error 1213 que debe procesar en el lado del cliente
Tenga en cuenta que un interbloqueo y una espera de bloqueo son cosas diferentes. En un interbloqueo, no hay transacción "fallida":ambos son culpables. No hay garantía de cuál se revertirá.
Se produce un interbloqueo en un escenario como este:
UPDATE t_first -- transacion 1 locks t_first
SET id = 1;
UPDATE t_second -- transaction 2 locks t_second
SET id = 2;
UPDATE t_second -- transaction 1 waits for transaction 2 to release the lock on t_second
SET id = 2;
UPDATE t_first -- transaction 2 waits for transaction 1 to release the lock on t_first. DEADLOCK
SET id = 2;
¿Estás seguro de que no lo estás confundiendo con una espera de bloqueo?
Se produce una espera de bloqueo cada vez que una transacción intenta bloquear un recurso que ya está bloqueado por otra transacción.
En el ejemplo anterior, se produce una espera de bloqueo en el paso 3 .
Dado que esta es una situación normal (a diferencia de un interbloqueo), que se puede resolver desde el exterior confirmando o revirtiendo la transacción que mantiene el bloqueo, InnoDB no intentará deshacer la transacción que mantiene el bloqueo.
En su lugar, simplemente cancelará la declaración que intentó adquirir el bloqueo después de que se agote el tiempo de espera.
El tiempo de espera por defecto es 50 segundos y se configura usando innodb_lock_wait_timeout
.
La declaración fallida (aquella que trató de adquirir la cerradura) devolverá el error 1205 .
