2017-04-26 1 views
0

Journaux indiquant que cette erreur est parfois déclenchée. Je lis le docs et c'est très déroutant car nous ne verrouillons aucune table pour faire des insertions et nous n'avons aucune transaction au-delà des appels SQL individuels. Donc, cela peut-il se produire parce que nous sommes à court de ma piscine de connexion mySQL dans Node? (Nous l'avons réglé à quelque chose comme 250 connexions simultanées). J'essaie de comprendre comment reproduire cela mais sans avoir de chance.ER_LOCK_DEADLOCK appelé lorsqu'il n'y a pas de verrou

Répondre

1

Chaque requête ne fonctionne dans une transaction explicite exécute dans une transaction implicite qui engage immédiatement lorsque la requête se termine ou annule si une erreur se produit ... alors, oui, vous utilisez les transactions. Les blocages se produisent quand au moins deux requêtes sont en train d'acquérir des verrous, et chacun d'entre eux contient des verrous au niveau des lignes qu'ils ont acquis dans un ordre tel qu'ils ont maintenant besoin d'un autre verrou que l'autre détient - - Alors, ils sont "dans l'impasse". Une condition d'attente infinie existe entre les requêtes en cours d'exécution. Le serveur remarque cela.

L'erreur n'est pas vraiment une faute car c'est le serveur qui dit: "Je vois ce que vous avez fait, là ... et, de rien, je l'ai nettoyé pour vous parce que sinon, vous auriez attendu pour toujours." Ce que vous ne voyez pas, c'est qu'il y a deux parties coupables - deux requêtes différentes qui ont causé le problème - mais une seule d'entre elles est punie. La requête qui a accompli le moins de travail (certes, ce concept est nébuleux) sera tuée avec l'erreur de blocage, et l'autre requête avancera heureusement sur son chemin, n'ayant aucune idée que c'était le survivant chanceux. C'est pourquoi le message d'erreur deadlock se termine par "try restarting transaction" - qui, si vous n'utilisez pas explicitement transacrions, signifie simplement "réexécutez votre requête".

Voir https://dev.mysql.com/doc/refman/5.6/en/innodb-deadlocks.html et examiner la sortie de SHOW ENGINE INNODB STATUS;, qui vous montrera l'autre requête - celle qui a provoqué le blocage mais qui n'a pas été tué - ainsi que celle qui l'a été.

+0

est donc sûr d'attraper cette erreur et il suffit de réexécuter la requête? Ou est-il préférable de le renvoyer à l'API et de soumettre à nouveau l'ensemble de la requête qui aboutit à cette requête? –

+0

Réessayer la requête vous-même, immédiatement ... ou plus tard (en renvoyant une erreur à l'API et en rappelant l'appelant) devrait être équivalent à la perspective de la base de données. –