Requètes SQL et temps d'exécution...

[Sarc]

Salut à vous tous...

Tout d'abord, désolé pour le titre peu explicite, j'étais pas très inspiré.

J'ai placé ce sujet dans PHP parce que je m'intéresse au traitement PHP d'une page, plus qu'à une seule requète SQL.

En fait, je crois avoir un souci de taille sur mon site : les exécutions simultanées (ou presques) d'un programme par deux membres.

J'explique en dessin :

Si Toto exécute le programme à l'instant t, qu'il finit à t+dt... Si Dupond exécute son programme à t+dt/2, nous sommes d'accord que le Sélect renverra deux fois la même chose.

Seulement, l'update de Toto aurait du empêcher Dupond d'exécuter le programme ! En effet, je veux que l'update du premier programme bloque un truc (symbolisé par le if...), qui ne permettrait pas à Dupond de le faire.

Je sais que l'exécution simultanée d'une même page par deux membres est plutôt rare. Mais tout porte à croire que c'est arrivé sur Pitimonde, il y a quelques jours, quand tous les fidèles, au taquet, se sont retrouvés à rafraîchir leurs pages toutes les secondes, et foncer sur certaines choses disponibles...

Or je me suis retrouvé avec deux membres sur la même chose. ><

Bref, je parle je parle, mais j'ai toujours pas posé de question :

Comment éviter ce phénomène ? Comment être sûr de pas me retrouver avec ce genre de situation ?

Merci d'avance de m'éclairer sur la question...

[captain_torche]

Ca ne serait pas gérable avec la syntaxe LOCK de Mysql ? (je ne l'ai jamais utilisée, mais il semble que ça corresponde).

[Sarc]

Héhé, tu t'es fait le pari d'être le premier à répondre à tous mes Topics ?

J'ai bien lu l'article que tu m'as donné, et il semble effectivement pouvoir répondre à mes attentes...

Cependant, j'ai une question : à quoi équivaut un thread ? C'est une connexion à la base ?

Dans ce cas-là, il faut que je fasse attention à ne pas faire ça :

connexion

lock table

select in table

deconnexion

connexion

update

deconnexion

parce que le lock serait tué avec la deconnexion...

Va falloir que je réflechisse bien à où placer des lock pour ne pas ralentir l'exécution des scripts (enfin, ça devrait pas excéder la seconde, je pense...)

[Kioob]

sarc : de manière générale si tu fais plusieurs deco/reco dans une meme "page", c'est que ton code a un sérieux soucis également

Sinon pour le problème principal, il y a souvent plusieurs solutions :

- les transactions : l'idéal, mais pas toujours évident à mettre en place

- mieux gèrer l'ordre des requetes : selon la complexité du code, en replaçant le code dans un ordre différent on peut parfois éviter les problèmes d'accès concurrents. Mais, garde à ne pas se louper...

- le lock : pour moi c'est la méthode "bourrine" par excellence, mais qui a au moins le mérite d'etre simple à mettre en place

[Anonymus]

Une autre solution (utilisée par phpmyadmin apparemment) est de vérifier que les données soient toujours celles qu'on pense..

Bon, un p'tit exemple :

TOTO :

SELECT * FROM produits WHERE produit_id = 1 AND stock = 1

DUPONT :

SELECT * FROM produits WHERE produit_id = 1 AND stock = 1

Toto achète (puisque stock= 1) :

TOTO :

UPDATE produits SET stock=stock-1 WHERE produit_id=1 AND stock=1

Dupont achète, puisque quand il a vérifié, il y avait toujours '1' en stock :

DUPONT :

UPDATE produits SET stock=stock-1 WHERE produit_id=1 AND stock=1

Normalement, on se contente de dire 'produit_id=xx'.

Avec la condition 'stock=1', on est sûr de l'intégrité des données.

Mais on peut mettre aussi :

UPDATE produits SET products_name='couteau WHERE produit_id=1 AND products_name='cuillere' AND products_description='une petite cuillere pour pitimonde' AND, AND..

En mettant tous les champs, on s'assure que l'enregistrement n'a pas été touché avant la modif.

Par contre, il va falloir prévoir le cas où, effectivement, l'update ne retourne rien : pas de champs modifiés, donc l'update n'a pas eu lieu

Mais.. c'était la question, non ?

Nico.