Discussion :

[renaud26]

Bonjour à tous,

D'un côté des requêtes INSERT dans 2 tables. (par les clients)
De l'autre, des requêtes UPDATE sur les mêmes tables. (par les admin)

Il y a des risques de conflit. Je souhaiterais utiliser LOCK TABLE et j'ai lu la doc MySQL sur le propos - doc d'une clarté limpide, comme d'habitude mais je ne voudrais pas faire d'âneries.

Je vous pose donc ces questions :

- Faut il faire LOCK WRITE / UNLOCK sur les requêtes des 2 côtés ? Ou un seul suffit ?
- Ou alors des 2 côtés mais en définissant des priorités ?
- Si il faut le faire que d'un côté, lequel ? celui qui INSERT ou celui qui UPDATE ?

Bref je veux bien quelques précisions sur le sujet.
Merci d'avance.

[Benjamin Delespierre]

Vu que les requêtes sur une même table sont exécutées séquentiellement, on n'a généralement pas besoin d'utiliser les lock. Il faudrait que tu nous en dise un peu plus sur ton schéma producteur / consommateur pour qu'on te réponde clairement.

[renaud26]

Bonjour et merci de me répondre,

Oui, il s'agit de la gestion d'une boutique qui tourne assez bien : il y a la table "commandes" - qui enregistre un résumé de commande puis génère un commande_id, et "commande_details" qui enregistre autant de lignes qu'il y a de produits commandés, avec prix, quantités...etc. Elle a bien sûr un champ "commande_id" qui permet ensuite de lier les requêtes select.

Chaque fois qu'un client enregistre une commande, toutes les 10mn, on va dire, on écrit en insert dans ces deux tables.

Mais côté admin, 2 personnes écrivent aussi dans ces 2 tables, en update, toutes les 10 mn, on va dire aussi, puisqu'elles génèrent des factures et valident les quantités livrées par rapport aux quantités commandées.

Et j'ai remarqué, parfois, des erreurs d'update (côté admin, donc) incompréhensibles et impossibles à reproduire, des trucs farfelus. Ca se produit parfois 1 fois par jour, parfois 1 fois tous les 2 jours...c'est complètement aléatoire.

Alors, je me suis dit qu'il y avait peut-être conflit, et, de façon à éliminer cette piste, j'ai pensé aux verrous...

Voili-voilou...

[Benjamin Delespierre]

C'est à creuser...

Imaginons le scénario suivant
- L'utilisateur A enregistre la commande CA
- L'admin B modifie la commande CA
- Au même moment L'utilisateur A consulte et modifie sa commande CA
- L'admin B valide la commande CA

L'une des modification devra (lock ou non) être affecté avant l'autre, si j'étais toi je chercherai s'il n'y a pas une erreur de logique quelque part, normalement, le dernier utilisateur ou administrateur à "parler" à la base devrait écraser les modifications précédentes... Donc et à moins que tu n'aies mis un mécanisme de cache, tout devrait se passer normalement.

[renaud26]

En fait, j'ai omis de préciser que c'est dans la table "commande_details" que se produisent les loups. Celle des commandes n'enregistre qu'une ligne par commande, et n'est updatée que d'un champ côté admin. Donc, si conflit il y a, c'est plus rare.

Par contre, dans "commande_details" :

L'utilisateur A passe une commande de mettons 10 produits.
La boucle parcoure le caddie et enregistre 10 lignes dans la table.
....
En même temps, l'admin X update la même table, mais forcément un autre commande_id, sur une commande qui fait aussi, admettons, 10 lignes.

Ca peut pas se parasiter, dans ce cas ?
Et, non, pas de système de cache ici.

[Benjamin Delespierre]

Ah oui effectivement, je comprends mieux. Je pense en effet que tu as besoin des locks des deux cotés:
- L'utilisateur doit attendre que l'admin ait fini d'opérer sur sa commande
- L'admin doit attendre que l'utilisateur ait fini de compléter sa commande pour la modifier
A mon avis il faut le faire des deux cotés car que se passerait-il si par exemple tu donnais plus de priorité à l'utilisateur et qu'il édite sa commande pendant que l'admin fait la même chose ?

Il y a deux écoles: soit tu attends que le lock soit levé (avec un slip propre ) soit tu affiche un message d'erreur indiquant que la commande est en cours de traitement par un autre processus.

[renaud26]

Ben c'est toute ma question, justement

Je dirais que le client est prioritaire sur l'admin (ne serait-ce que parce que sans client, l'admin, ben il a pas de taf ) et donc je pensais LOCK / UNLOCK uniquement côté public, en me disant que l'admin, pour son UPDATE, devra attendre que le client ait fini et que les tables soient UNLOCK.

Non ?

Parce que à ce stade, le client il édite rien, il update pas. Ses données s'insèrent en table et c'est fini.

[EDIT]

tu affiche un message d'erreur indiquant que la commande est en cours de traitement par un autre processus

Ah ? ET comment on fait ça ? Comment on sait, côté admin, qu'une commande client est en train de s'insérer ?
Ca m'intéresse bigrement, parce que tu imagines...2 admins !

[Benjamin Delespierre]

En te servant de GET_LOCK peut être

Non ?

Non. A mon avis, il faut poser le lock des deux coté pour éviter qu'un utilisateur ne parasite le travail d'un admin. De toute façon, si tes requêtes sont suffisament optimisées, l'attente de la levée du lock ne devrait pas être longue et comme tu l'as dit toi même, les collisions sont peu nombreuses, l'impact coté client est pratiquement nul.

[renaud26]

Humm, je n'ai pas capté grand chose à GET_LOCK, mais tant pis.
Décidément, cette doc Mysql...est vraiment, euh...ésotérique.

J'ai suivi ton conseil, et mis un verrou des deux côtés.
On va bien voir.
Je te remercie bien pour ton aide.
Bonne fin de journée.