Discussion :

[philippelorin]

Bonjour à tous,

Je suis d'accord sur les principes généraux mais certaines situations ne laissent que très peu de choix.

En effet, si je supprime une ligne de la table 'pere' (num=2), la table 'fils' est cette fois-ci totalement bloquée !
Je vais voir ce que je peux faire afin de débloquer cette situation.

C'est exactement le problème que je n'arrive pas à expliquer :
pourquoi la suppression d'une ligne d'une table A bloque toute création de ligne dans une table B?
Y a-t-il une explication ?
Y a-t-il un paramétrage à faire pour éviter ce problème ?
Y a-t-il une explication logique ?

Merci,

@+

[aieeeuuuuu]

Oui, il y a une explication logique :

Le verrouillage ne se fait pas systématiquement au niveau ligne, il peut-être plus large, et c'est le cas ici. le verrouillage peut concerner des plages de valeurs.

si vous essayez d'insérer des données avec des valeurs différentes dans la table fils (autre que 1 comme père) ça fonctionne. Ce n'est donc pas la table complète qui est verrouillée, mais une partie seulement.

un peu de lecture sur le verouillage :

[philippelorin]

Bonjour,

Comment connaitre la plage de valeurs verrouillées ?

[Artemus24]

Salut Philippelorin.

Je suis d'accord sur les principes généraux mais certaines situations ne laissent que très peu de choix.

Vos explications concernant le problème que vous rencontrez est sans solutions.
Comme je le suppose, vous faites un mauvais usage du mode transactionnel sous MySql.
Ayant cherchez dans la documentation de MySql, je n'ai rien trouvé de probant pour résoudre ce genre de problème.
Selon moi, vous vous focalisez trop sur le problème que vous rencontrez.

Vous devriez nous expliquer ce que vous qualifiez de "certaines situations" car je n'ai toujours pas compris ce que vous essayez de faire.
Je parle du traitement informatique, ainsi que de la manière dont vous le faite.

Si j'ai bien compris, vous devez faire une mise à jour dans cette base de données.
Ce qui pose problème, c'est que la validation est soumise au bon vouloir d'un utilisateur qui prend son temps.
Et en conséquence de quoi, un autre utilisateur se retrouve bloqué.

Normalement, il faut faire cela en deux temps.
1) vous lisez par une requête SQL (hors transaction) l'information dont vous désirez modifier.
Vous présentez la modification à faire à votre utilisateur qui va soit la valider ou soit la rejeter.
Ici, il peut prendre son temps car il ne bloque personne. S'il la rejette, on ne fait pas la phase 2) ci-après.

2) admettons que l'utilisateur valide cette modification.
Maintenant, vous rentrez dans le mode transactionnel.
Vous relisez la requête en la bloquant (mode IX).
Si quelqu'un d'autre bloque la ligne en question, la seule façon de ne pas se faire jeter est d'augmenter le timeout.

Vous vérifiez qu'elle n'a pas déjà été modifié entre temps.
Si elle a été modifiée, vous faites un "rollback", et vous revenez au cas 1) afin de recommencer cette phase.
Si elle n'a pas été modifiée, vous faites la mise à jour et vous faites un "commit".
Cette phase 2) prend très très peu de temps et ne bloque quasiment personne car il n'y a aucune intervention humaine !!!

Je pense que vous désirez tout faire en une seule phase, à savoir :
Lecture de la requête SQL (en mode transaction).
Vous présentez la modification à l'utilisateur qui va soit la valider ou soit la rejeter.
Et c'est là que l'utilisateur prend son temps et risque de bloquer les autre utilisateur.
Si l'utilisateur la valide, vous faite la mise à jour et vous faites un "commit".
Si l'utilisateur la rejette, vous faites un "rollback".

Le problème avec cette façon de procéder, c'est que vous bloquez une ligne et cela prend énormément de temps.
D'où l'anomalie que vous rencontrez !

J'ai poursuivi le test.
Je suis en "repeatable read" dans tous les cas.

CAS A) il n'existe pas de lignes (cle=2) dans la table 'fils'. On demande la suppression dans la table pere (num=2) Il y a un blocage sur la totalité de la table 'fils'.

CAS B) il existe au moins une ligne (cle=2) dans la table 'fils'. On demande la suppression dans la table pere (num=2). Il n'y a pas de blocage pour l'insertion d'une ligne ayant cle=1 ou 3 dans la table 'fils'. Par contre pour cle=2, il y a bien un blocage.

Je n'ai aucune explication sur la raison du blocage de la totalité de la table 'fils' pour le cas A) quand on désire supprimer une ligne (sans commit) alors que cette ligne n'existe pas.

@+

[philippelorin]

Salut Artemus24,

Je pense que vous désirez tout faire en une seule phase, à savoir :
Lecture de la requête SQL (en mode transaction).
Vous présentez la modification à l'utilisateur qui va soit la valider ou soit la rejeter.
Et c'est là que l'utilisateur prend son temps et risque de bloquer les autre utilisateur.
Si l'utilisateur la valide, vous faite la mise à jour et vous faites un "commit".
Si l'utilisateur la rejette, vous faites un "rollback".

Vous avez bien compris la situation. C'est le comportement d'une application développée avec windev ou les données sont directement raccordées à la base de donnée. Il n'y a pas de couche intermédiaire comme dans une application MVC.

CAS A) il n'existe pas de lignes (cle=2) dans la table 'fils'. On demande la suppression dans la table pere (num=2) Il y a un blocage sur la totalité de la table 'fils'.

Toute la table ne semble pas bloquée mais un plage de donnée. Le fait de ne pas savoir à l'avance la plage qui va être bloquée est problématique.
Ce cas restera un mystère.

Merci pour votre contribution et pour le temps passé sur le sujet.

@+

[aieeeuuuuu]

Je ne pense pas que MySQL permette de voir les verrou posés a un instant t, mais vous pouvez voir les verrous causant des attentes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
select *
from information_schema.innodb_locks;