transaction Mysql en attente d'un verrou qui est déjà accordé .. Ceci provoque un blocage

Question

Si la situation suivante un bug dans mysql ?.

Mysql Version: mysql.x86_64 5.0.77-4.el5_4.1

noyau: Linux box2 2.6.18-128.el5 # 1 SMP Mer 21 janvier 2009 10:41:14 EST x86_64 x86_64 x86_64 GNU/Linux

------------------------ 
LATEST DETECTED DEADLOCK 
------------------------ 
100125 4:24:41 
*** (1) TRANSACTION: 
TRANSACTION 0 210510625, ACTIVE 155 sec, process no 28125, OS thread id 1243162944 starting index read 
mysql tables in use 1, locked 1 
LOCK WAIT 5 lock struct(s), heap size 1216, undo log entries 1 
MySQL thread id 162928579, query id 527252744 box22 172.16.11.105 user updating 
delete from user_grid_items where user_id = 669786974 and START_X = 45 and START_Y = 65 
*** (1) WAITING FOR THIS LOCK TO BE GRANTED: 
RECORD LOCKS space id 0 page no 61372 n bits 328 index `PRIMARY` of table `gamesutra_beta/user_grid_items` trx id 0 210510625 lock_mode X locks rec but not gap waiting 
Record lock, heap no 127 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 
0: len 8; hex 0000000027ec235e; asc  ' #^;; 1: len 4; hex 0000002d; asc -;; 2: len 4; hex 00000041; asc A;; 3: len 6; hex 00000b561243; asc V C;; 4: len 7; hex 80000040070110; asc @ ;; 5: len 23; hex 474949445f414e494d414c535f53515549445f50494e4b; asc GIID_ANIMALS_SQUID_PINK;; 6: len 4; hex cb59f060; asc Y `;; 7: len 4; hex 4b59f060; asc KY `;; 8: len 4; hex 80000000; asc  ;; 9: len 1; hex 80; asc ;; 

*** (2) TRANSACTION: 
TRANSACTION 0 210505911, ACTIVE 555 sec, process no 28125, OS thread id 1184323904 starting index read, thread declared inside InnoDB 500 
mysql tables in use 1, locked 1 
5 lock struct(s), heap size 1216, undo log entries 1 
MySQL thread id 162924258, query id 527252762 box22 172.16.11.105 user updating 
delete from user_grid_items where user_id = 669786974 and START_X = 45 and START_Y = 65 
*** (2) HOLDS THE LOCK(S): 
RECORD LOCKS space id 0 page no 61372 n bits 328 index `PRIMARY` of table `gamesutra_beta/user_grid_items` trx id 0 210505911 lock mode S locks rec but not gap 
Record lock, heap no 127 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 
0: len 8; hex 0000000027ec235e; asc  ' #^;; 1: len 4; hex 0000002d; asc -;; 2: len 4; hex 00000041; asc A;; 3: len 6; hex 00000b561243; asc V C;; 4: len 7; hex 80000040070110; asc @ ;; 5: len 23; hex 474949445f414e494d414c535f53515549445f50494e4b; asc GIID_ANIMALS_SQUID_PINK;; 6: len 4; hex cb59f060; asc Y `;; 7: len 4; hex 4b59f060; asc KY `;; 8: len 4; hex 80000000; asc  ;; 9: len 1; hex 80; asc ;; 

*** (2) WAITING FOR THIS LOCK TO BE GRANTED: 
RECORD LOCKS space id 0 page no 61372 n bits 328 index `PRIMARY` of table `gamesutra_beta/user_grid_items` trx id 0 210505911 lock_mode X locks rec but not gap waiting 
Record lock, heap no 127 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 
0: len 8; hex 0000000027ec235e; asc  ' #^;; 1: len 4; hex 0000002d; asc -;; 2: len 4; hex 00000041; asc A;; 3: len 6; hex 00000b561243; asc V C;; 4: len 7; hex 80000040070110; asc @ ;; 5: len 23; hex 474949445f414e494d414c535f53515549445f50494e4b; asc GIID_ANIMALS_SQUID_PINK;; 6: len 4; hex cb59f060; asc Y `;; 7: len 4; hex 4b59f060; asc KY `;; 8: len 4; hex 80000000; asc  ;; 9: len 1; hex 80; asc ;; 

*** WE ROLL BACK TRANSACTION (2) 
------------ 

Answer 1

Utilisez SHOW ENGINE INNODB STATUS pour déterminer la cause de la dernière impasse. Cela peut vous aider à régler votre application pour éviter les blocages.

Soyez toujours prêt à réexécuter une transaction si elle échoue en raison d'un blocage. Les deadlocks ne sont pas dangereux. Réessayez.

Answer 2

J'ai lu quelque chose il y a longtemps, et je ne sais pas si cela pourrait être ce que vous êtes en train de rencontrer ou non ... sans voir le code de la transaction de l'actuel vs ce qui est en conflit avec. Lors du traitement de vos transactions, vous devez essayer de les verrouiller toujours dans le même ordre ... Pour un système de commande/commande/paiement, effectuez les activités dans l'ordre indiqué dans l'exemple ci-dessous pour tous les produits similaires. Si vous avez un autre processus qui tente sa transaction dans l'ordre de "Commande/commande", cela peut entraîner un blocage.

Une transaction verrouille d'abord le numéro de commande, puis le détail de la commande. L'autre transaction verrouille d'abord le détail de la commande, puis essaie d'obtenir l'en-tête de la commande.

HTH

Answer 3

Parfois SHOW STATUS MOTEUR INNODB peut être difficile à déchiffrer, car il montre que l'instruction en cours dans la transaction. Il n'affiche pas les instructions qui se sont produites précédemment dans la même transaction et qui ont peut-être acquis les verrous réellement détenus.

Dans votre cas, une instruction précédente dans la transaction 2 a acquis un verrou partagé sur la ligne en question. Ensuite, la transaction 1 a tenté d'acquérir un verrou exclusif sur la même ligne et attend avec bonheur que le verrou partagé soit supprimé. Ensuite, la transaction 2, dans une autre instruction, a tenté d'acquérir un verrou exclusif sur la même ligne. Impasse classique. Aucune transaction ne peut terminer. Une solution pour éviter un tel blocage serait de saisir un verrou exclusif sur la ligne de la transaction 2 avec une instruction SELECT FOR UPDATE, avant l'instruction d'acquisition du verrou partagé.