PDO, transactions, LOCK TABLE et LOCK IN SHARE MODE

[php_addict]

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
{
    $num_rows=0;
    //
    // tant qu'il y a des elements succeptible d'être traités, on fait une boucle
    //
    while ($num_rows>=1)
    {
    $connexion->beginTransaction();  
    $result=$connexion->query("SELECT id FROM table WHERE $time>=time LOCK IN SHARE MODE");
    $num_rows = $resultats->rowCount();
    //
    // ici on va traiter tout un tas de table differente en SELECT IN LOCK SHARE MODE
    // et faire des operation d'ecriture et d'effacement sur des tables
    //
    }
    $connexion->commit();
}
catch(PDOException $e)
{
    $connexion->rollBack();
    exeption($e);
}

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 ;-)

[Zamentur]

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

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?

[php_addict]

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)

[Ekilio]

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 :

<?php 

// Début de la transaction

$pdo->beginTransaction();



// Select et verrouillage de la table

$pdo->query('SELECT id FROM table LOCK IN SHARE MODE');



// A partir de maintenant, aucune modification ne peut être faite

// sur la table "table". En revanche, tout le monde peut lire les informations

// sur cette même table.

// On execute différentes requêtes maintenant, tout ce qu'on veux



// On commit

$pdo->commit();



// A présent la table est déverrouillée et tout le monde peut la modifier 

[Ter Rowan]

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:

[Sephi-Chan]

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

[php_addict]

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:$

[Sephi-Chan]

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

[christouphe]

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

[Sephi-Chan]

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