Serialization failure: aie aie ai !!! Deadlock

[php_addict]

bonjour

je sollicite humblement et curieusement votre aide sur un point précis, les deadlock anvec innodb de mysql

quand on ('fin moi) a ce type d'erreur:

Code :

exception 'PDOException' with message 'SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction'

c'est bien que:

1) une transaction est lancée, elle lock des tables en posant des verrous
2) une autre transaction est lancée alors que la premiere n'est pas terminée sur la table lockée
3) et bang! dealock

j'ai bon c'est bien comme ca que ca fontionne?

j'ai en principe des rollback partout, donc ce n'est pas grave finalement ce deadlock, non? si? j'sais plus du tout, help! au secours! :cogne: faut pas se louper sur les rollback c'est tout non?

et en bonus si vous pouvez m'expliquer où mysql pose les verrous, sur des tables complètes? sur des lignes de la table (en gros est ce que tout la table mysql est lockée ou seulement les lignes concernées) ?

merci de m'avoir lu

A bientôt pour de nouvelles questions existentielles sur les deadlock (j'ai ai quelque unes en réserves

salutation distinguées

[php_addict]

z'avez pas d'avis sur ma question existentielle du moment? snif snif...

bonne journée

[keke]

Le dead lock, c'est quand tu as 2 transactions qui s'autoblock. C'est un peu plus compliqué que ce que tu signales.

Par exemple,
Trans1 modifie table A puis table B

Trans2 modifie table B puis table A

Tu lances les 2 en même temps.
Trans1 lock la table A
Trans2 lock la table B

Trans1 veut modifier la table B ... comme elle est lockée, elle attend.
Trans2 veut modifier la table A ... comme elle est lockée, elle attend.
Et là, tu peux attendre longtemps avant que le système comprenne comment résoudre. Et peut importe tes procédures de rollback.

Dans ton exemple, je cite :
>>> 1) une transaction est lancée, elle lock des tables en posant des verrous
>>> 2) une autre transaction est lancée alors que la premiere n'est pas terminée sur la table lockée
>>> 3) et bang! dealock
Dès que la première transaction est finie, tout se décoince ... C'est d'ailleurs l'utilité des Locks en base de données.

Je t'ai peut-être aidé mieux appréhender ton problème.

kéké

[Roworll]

Le terme français pour Deadlock est "interblocage".
L'article correspondant de Wikipedia explique simplement ce phénomène.

D'une manière générale, les transactions peuvent s'empiler et se dépiler sans problème.
Le Deadlock est un cas bien particulier qui, même s'il est lié aux transactions et aux verrous, n'apparait que si certaines conditions sont présentes.

Maintenant, concernant les verrous de MySQL, pour ce que j'en sais, si tes tables sont en format de stockage MyIsam, les verrous sont posés sur les tables entières uniquement. Avec InnoDB, les verrouillages sont effectués au niveau de la ligne et peuvent être partagés (read) ou exclusifs (update/delete).
Tu peux également influer sur le niveau d'isolation des transactions avec SET TRANSACTION ISOLATION LEVEL pour éviter les verrouillages intempestifs lors des lectures ou au contraire t'assurer de la bonne cohérence des données.

Et pour tenter de répondre à ta question principale qui est :

j'ai en principe des rollback partout, donc ce n'est pas grave finalement ce deadlock, non? si? j'sais plus du tout, help! au secours! :cogne: faut pas se louper sur les rollback c'est tout non?

Je dirais que ça dépend.
Ça dépend de la manière dont tes transactions sont imbriquées, à quel niveau de profondeur se situe le deadlock la manière dont l'erreur est gérée, etc.

[php_addict]

salut

ok ok, merci pour vos explications:

je pensais que les transactions était exécutées les unes après les autres, genre:

- un process 1 lance une transaction T1
- un process 2 lance une transaction T2 quasi au même moment que le process 1
--> mysql exécute la transaction T1 puis la T2 quand la T1 est terminée

c'est pas du tout ça alors???

[srm]

Commence déjà par passer tes tables en innoDb si elles ne le sont pas.
Ensuite met un système pour benchmarker tes transactions pour voir le temps de chacune.

Et pour finir, pourquoi as tu besoin de transactions ?

[php_addict]

mes tables sont en innodb heureusement
je fais le max : " SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE "

comme pour le moment pour mes résolutions d'actions (jeu en temps reel) je n'utilise pas de système de queue schedulding géré par un seul process/deamon il y a quelques concurrences d'accès à la base de donnée, très peu (si si je vous assure...) reste mais ca risque de mettre le binz...

là j'ai installé un debian sur un pc pourri pour me confronter au problème de resque schedulding et compagnie, mais c'est pas gagné...une épreuve pour moi

sais tu si, et je me cite : "je pensais que les transactions était exécutées les unes après les autres"

bonne soirée

[niahoo]

salut

ok ok, merci pour vos explications:

je pensais que les transactions était exécutées les unes après les autres, genre:

- un process 1 lance une transaction T1
- un process 2 lance une transaction T2 quasi au même moment que le process 1
--> mysql exécute la transaction T1 puis la T2 quand la T1 est terminée

c'est pas du tout ça alors???

Ben si c'est ça à condition que la t1 lock des tables utilisées par la t2. sinon elles peuvent se faire en même temps.

faudrait que tu nous montres la requête ... je vois pas trop comment on peut arriver à un deadlock avec de simples requêtes SQL.

[php_addict]

faudrait que tu nous montres la requête ... je vois pas trop comment on peut arriver à un deadlock avec de simples requêtes SQL.

dès que je peut oui, lundi...

[srm]

Tu as tout mis dans tes transactions ou juste les requêtes qui pouvaient poser soucis sans transaction ?