PDO, transactions, LOCK TABLE et LOCK IN SHARE MODE - Version imprimable +- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org) +-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38) +--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51) +--- Sujet : PDO, transactions, LOCK TABLE et LOCK IN SHARE MODE (/showthread.php?tid=4552) |
PDO, transactions, LOCK TABLE et LOCK IN SHARE MODE - php_addict - 22-01-2010 bonjour tout d'abord merci à Ekilio pour sa reponse en mp, mais je galere toujours sur ce sujet: transactions en PDO et les LOCK TABLE je voudrais traiter des entrées dans ma base de donnée en utilisant une transaction pour faire des ajout et suppression d'entrée dans differentes tables. MAIS ce traitement de donnée ne doit pas etre effectué au meme moment par plusieurs joueurs connectés je me suis donc penché vers les LOCK TABLE mais je ne suis pas certain de comprendre la difference entre LOCK TABLE et SELECT LOCK IN SHARE MODE lequel des deux dois je utiliser? et j'ai cru comprendre qu'avec les transaction PDO les LOCK posent soucis voici mon pseudo code: Code : try merci a ceux qui ont pris le temps de lire ce pseudo code car je sais que ce n'est pas toujours tres agreable... est ce que les LOCK IN SHARE MODE bloquent l'acces totalement durant le SELECT et faut-t-il unLOCKer les table apres une telle requete? quels conseils avisés de grand chef SQL me conseillez vous au sujet des LOCK ? encore merci ;-) RE: PDO transactions et LOCK TABLE et LOCK IN SHARE MODE - Zamentur - 22-01-2010 (22-01-2010, 12:29 PM)php_addict a écrit : je voudrais traiter des entrées dans ma base de donnée en utilisant une transaction pour faire des ajout et suppression d'entrée dans differentes tables. Ben c'est un peu le but des transactions non? Le verrou d'écriture sera obtenu pour toutes les tables utilisées. T'as réussi à faire un test qui contredit le fait que la transaction suffit? RE: PDO transactions et LOCK TABLE et LOCK IN SHARE MODE - php_addict - 22-01-2010 a priori une transaction ne sert pas a ca mais sert a traiter un ensemble de requete d'un seul coup et pouvoir revenir en arriere en cas de pepin dans le cas d'un script avec une transaction lancé au meme moment par 2 internautes differents et bien mon script est executé 2 fois parfois ce que je veux empecher à tout prix (pas trop cher quand meme ;-) j'ai fais le test en ajax avec 4 navigateur differents logé en session et je n'arrive pas a mon resultat: que le script ne soit executé qu'une seule fois (et pas 4) RE: PDO transactions et LOCK TABLE et LOCK IN SHARE MODE - Ekilio - 22-01-2010 Quelques petites choses : - D'abord, les LOCK ne sont pas compatibles avec les transactions ; lorsque tu executes un lock, MySQL fait un commit immédiatement et ferme toutes les transactions. - Ensuite, LOCK IN SHARE MODE permet un verrouillage uniquement en écriture. Celle-ci fonctionne avec les transactions (en fait, c'est même son seul but vu que les SELECT sont atomiques, donc n'ont pas de temps d'execution). La différence est le temps de verrouillage. Voici un exemple : Code PHP :
Ce n'est donc pas un verrouillage complet : la table n'est verrouillée qu'en écriture, et sera déverrouillée au commit. Le LOCK par contre ne sera comme je l'ai dit pas compatible avec les transactions, et la table devra être déverrouillée au final. RE: PDO transactions et LOCK TABLE et LOCK IN SHARE MODE - Ter Rowan - 22-01-2010 n'empêche php_addict, je suis solidaire avec toi ce sera bientôt mon tour d'avoir les mêmes problématiques tiens bon, y en a d'autres qui comptent sur toi :good: RE: PDO transactions et LOCK TABLE et LOCK IN SHARE MODE - Sephi-Chan - 22-01-2010 Je pense que tu comprends mal la notion de transaction. Utiliser une transaction permet de garantir que les requêtes adressée à la base entre le début de la transaction et son commit soit effectué sans que les données ne soit parasitées entre temps. Donc, dans ton test à 4 requêtes, tu peux être sûr que tes ensembles de requêtes ont bien été lancées l'un après l'autre. Si tu veux empêcher que ces ensembles de requêtes soient effectuées, il faut que tu utilises un flag (que tu affectera au sein de la transaction). Ainsi, il te suffira de tester ce flag dans la transaction pour savoir si oui ou non tu dois commencer/continuer à lancer les requêtes. Sephi-Chan RE: PDO transactions et LOCK TABLE et LOCK IN SHARE MODE - php_addict - 22-01-2010 (22-01-2010, 01:28 PM)Sephi-Chan a écrit : Si tu veux empêcher que ces ensembles de requêtes soient effectuées, il faut que tu utilises un flag (que tu affectera au sein de la transaction). Ainsi, il te suffira de tester ce flag dans la transaction pour savoir si oui ou non tu dois commencer/continuer à lancer les requêtes. donc pas besoin de LOCK ? quand tu parles de flag, j'imagine que c'est un champs "resolu" auquel on affect "1" ou "0" ou un truc du genre non? merci pour vos reponses, j'ai vraiment l'impression d'etre un gros nul:$ RE: PDO transactions et LOCK TABLE et LOCK IN SHARE MODE - Sephi-Chan - 22-01-2010 Voilà, c'est ça un flag. Et rassure toi, il n'y a pas de mal à découvrir des concepts et leurs applications ! Sephi-Chan RE: PDO transactions et LOCK TABLE et LOCK IN SHARE MODE - christouphe - 22-01-2010 Sephi, quand tu dis "[..]tester ce flag dans la transaction[..]", cela veut dire que tu considère une transaction comme un batch ? J'aime bien apprendre moi RE: PDO transactions et LOCK TABLE et LOCK IN SHARE MODE - Sephi-Chan - 22-01-2010 Je ne comprends pas trop ta question. Par "batch", tu parles bien d'une procédure automatisée ? Dans mon explication, et d'après ce que j'ai compris de son besoin, il souhaite n'effectuer qu'une seule transaction plutôt que les 4. Si c'est le cas, il suffit qu'en début de transaction, elle teste si elle doit être effectuée (pour ça, elle requête une entrée qui contient un flag). Si oui, elle fait se qu'elle a à faire puis affecte ledit flag pour que les prochaines transactions (à priori, la même que celle en cours) ne se déroulent pas (du moins, elles se dérouleront jusqu'à la consultation du flag). Sephi-Chan |