Serialization failure: aie aie ai !!! Deadlock

[php_addict]

enfin de retour, désolé...

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

- Toutes mes résolutions d'action sont dans des transactions (commit et rollback), et donc toutes les tables concernées (insert et update) sont en level d'isolation SERIALIZABLE

- Tout ajout d'actions dans les tables qui contiennent les actions à résoudre à un timestamp donné sont également INSERT dans des transactions

donc oui il y a des deadlocks qui viennent de là certainement...mais le hic c'est que je suis bien obligé d'avoir un niveau d'isolation élevé pour le script qui résoud les actions et les scripts qui ajoutent des actions

pour info j'ai une table "actions" qui contient quelques infos et un pointeurs vers d'autres table "actions_combattre" "action_mvt_de_troupes" etc...(ce ne sont pas les varies nom de mes tables je vous rassure, c'est à titre d'exemple....)

je crois que je n'est pour le moment pas compris tout et surtout les problèmes que cela peut poser en cas de deadlock...

[Myrina]

je crois que je n'est pour le moment pas compris tout et surtout les problèmes que cela peut poser en cas de deadlock...

Il n'y a pas 36 solutions; keke explique bien le problème.
Pour éventuellement trouver les transactions bloquantes, fait, pour chacune d'elle, la liste séquentielle des tables en INSERT/UPDATE et trouve les deux transactions en deadlock en recherchant les tables qui se croisent de l'une à l'autre. (table A puis table B ET table B puis table A)

Ensuite, soit tu peux réordonner tes ordres SQL (table A puis table B dans les deux transactions), soit il te faut trouver un mécanisme pour empêcher l'exécution de ces deux transactions en même temps.

[php_addict]

ok ok le debugage n'est quand meme pas bien simple...merci je vous tient au courant...

[srm]

Ca n'est pas pour rien que l'on t'a dit de fuir les transactions sauf absolu nécessité

Mais fait donc ce que je t'ai dit, pour avoir ce soucis tu dois avoir des transactions beaucoup trop longues, donc log la durée de chacune.
Car à ma connaissance tu as pas une charge de millions de visiteurs

[php_addict]

Ca n'est pas pour rien que l'on t'a dit de fuir les transactions sauf absolu nécessité

Mais fait donc ce que je t'ai dit, pour avoir ce soucis tu dois avoir des transactions beaucoup trop longues, donc log la durée de chacune.

oui effectivement je vais apporter des améliorations sur la vitesse, 'fin la durée des transactions...

Car à ma connaissance tu as pas une charge de millions de visiteurs

ah ba non, si seulement

[php_addict]

Bon...et bien là je ne comprends plus du tout du tout... j'ai encore des deadlock alors que je n'ai qu'une seule et unique transaction dans tout mes milliers de lignes de code

$query   = " SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE ";

$result  = $dbh->prepare("$query");  

$result->execute();  



try

{

   $dbh->beginTransaction(); 

   //

   // ici je résoud mes actions, autant dire que cela concerne pas mal de table mysql...

   //

   $dbh->commit();

}

catch(PDOException $e)

{

   log_exception($e);

   $dbh->rollBack();

}

et voici le message d'erreur renvoyé par log_exception($e) lors du rollback:

Code :

exception 'PDOException' with message 'SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction' in /var/www/xxxxxxxxxxxx.php:83

comment est t il possible d'avoir des deadlock alors que je n'ai qu'une seule transaction? y a t il des requetes qui implicitement initialisent des transactions?

alors là je ne comprends pas du tout...je suis largué, please help

[srm]

Montre le code qui correspond à // ici je rés...

[php_addict]

salut Oxman

il y a plus de 500Ko de code...mais a priori cela coince toujours dans des requêtes du genre:

$query   = "INSERT INTO liste ( time , v_id_actif , v_id_passif , nbr , resolu) VALUES ( :time_fin, :v_id_actif, :v_id_passif, 3 , '0')";

$result  = $this->dbh->prepare("$query");  

$result->execute(array(':time_fin' => $time_fin , ':v_id_actif' => $v_id_actif , ':v_id_passif' => $v_id_passif)); 

//

$sub_id=$this->dbh->lastInsertId();

//

$query   = "INSERT INTO liste_3 ( sub_id , aaa , bbb , ccc , ddd) VALUES ( ub_id , :aaa , :bbb , :ccc , :ddd )";

$result  = $this->dbh->prepare("$query");  

$result->execute(array('ub_id' => $sub_id , ':aaa' => $aaa , ':bbb' => $bbb , ':ccc' => $ccc , ':ddd' => $ddd)); 

	

y pas vraiment de raison que ca coince, non ?
lors d'une transaction on peut UPDATE la même ligne d'une même table plusieurs fois même si il y a un verrous, non?

à moins que cela viennent que 2 clients fasse la même requêtes au même moment...euh pas sûr...

merci

[srm]

500ko dans une transaction ?
Montre tout le code.

[php_addict]

il s'agit de 500Ko d'include, effectivement il s'agit des résolutions des actions (construire, attaquer, etc...)donc oui il y a quelques lignes de code, je vais pas mettre les 500Ko de code, beaucoup trop long, je vais essayer d'isoler le code...

sinon, y a t il moyen avec SHOW INNODB STATUS de savoir quels sont les scripts d'où viennent les deadlocks?

juste pour être certain d'avoir compris:

- une transaction commence et concerne la TABLE liste
- la TABLE liste est lockée
- un autre process tente de faire un INSERT dans la TABLE liste pendant que la transaction est encore en cours
- la transaction se termine

que se passe t il pour l'INSERT dans la TABLE liste pendant que la transaction est encore en cours ? attente de delockage? deadlock?

merci