Un interblocage renvoie l'erreur 1213 que vous devez traiter côté client
Notez qu'un interblocage et une attente de verrouillage sont des choses différentes. Dans une impasse, il n'y a pas de transaction « ratée » :ils sont tous les deux coupables. Il n'y a aucune garantie laquelle sera annulée.
Un blocage se produit dans un scénario comme celui-ci :
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;
Êtes-vous sûr de ne pas le confondre avec une attente de verrouillage ?
Une attente de verrouillage se produit chaque fois qu'une transaction tente de verrouiller une ressource déjà verrouillée par une autre transaction.
Dans l'exemple ci-dessus, une attente de verrouillage se produit à l'étape 3 .
Puisqu'il s'agit d'une situation normale (contrairement à un blocage), qui peut être résolue de l'extérieur en validant ou en annulant la transaction qui détient le verrou, InnoDB ne tentera pas d'annuler la transaction qui détient le verrou.
Au lieu de cela, il annulera simplement l'instruction qui a tenté d'acquérir le verrou après l'expiration du délai.
Le délai d'attente par défaut est 50 secondes et est défini à l'aide de innodb_lock_wait_timeout
.
La déclaration ratée (celle qui a tenté d'acquérir la serrure) renverra l'erreur 1205 .
