Discussion :

[anrow]

Bonjour,

Je suis actuellement en train de développer une petite application en PHP avec des accès à une base de données MySQL.

Dans le but de faire les choses assez proprement, j'ai décidé d'utiliser PDO avec toutes ses petites subtilités (requêtes préparées et gestion des transactions).

J'ai donc lu le manuel du PDO de Php (PDO) et j'ai essayé de me pencher sur le fonctionnement des transactions.

J'étais déjà au courant que cette technique permettait de garantir la cohérence de la base de données (lorsqu'on applique plusieurs modifications successives sur les tables de la base, par exemple), mais j'ai pu lire ailleurs que ça pouvait aider à gérer les accès concurrents (par exemple, on ne peut pas modifier les lignes d'une table qui sont déjà en train d'être modifiées).

J'en suis venu à me demander si, lors de l'exécution d'une requête SQL "SELECT", l'initialisation d'une transaction était nécessaire.
Je me doute bien que ça n'a pas d'intérêt pour ce qui est de garantir l'intégrité de la base de données (aucune modification n'étant réalisée) mais je me demandais si ça pouvait empêcher l'accès aux données étant déjà en cours de modifications ou si les systèmes de gestion de base de données le faisaient automatiquement.

Petit exemple :

Code :

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

1
2
3
4
5
6
7
8
9
 
$dbh = new PDO('mysql:host=localhost;dbname=test', $user, $pass);
 
$dbh->beginTransaction();
 
//Exécution d'un SELECT
$dbh->query('SELECT * FROM maTable');
 
$dbh->commit();

J'attends avec impatience vos explications.
Merci.

[Seb33300]

mais je me demandais si ça pouvait empêcher l'accès aux données étant déjà en cours de modifications ou si les systèmes de gestion de base de données le faisaient automatiquement

J'ai pas vraiment compris ta question

Mais si jamais ça peut y répondre, il me semble qu'une table est verrouillée en modification pendant toute la période ou elle est utilisée dans une requête notamment un SELECT

[anrow]

Désolé, j'ai essayé d'être clair, mais j'ai dû mal m'expliquer.

Je reprends.

D'après ce que j'ai compris, la gestion des transactions avec le PDO de PHP (en utilisant le beginTransaction() et le commit()) à pour principal intérêt de garantir la cohérence du contenu de la base de données. Ça permet, entre autre, de valider un ensemble de modifications réalisées sur la base de données d'un seul bloc (pour éviter que lors de l'exécution de plusieurs modifications qui s'enchainent, la base de données ne soit pas corrompue si un problème survient).

Sachant ça, lorsqu'on va exécuté seulement des requêtes SQL "SELECT" sur la base de données, il n'y a pas grand intérêt à utiliser les transactions, vu qu'il n'y a pas de modifications de réalisées.

Ensuite, j'ai cru comprendre que l'autre intérêt des transactions étaient de gérer les accès concurrents. Ça permettrait donc d'évider que des modifications soient réalisées sur des tables dont on manipulerait déjà le contenu.

C'est à ce niveau là que je me pose des questions : Est-ce que finalement il pourrait y avoir un intérêt à utiliser le système de transaction avec les requêtes SQL "SELECT", dans le but d'éviter l'accès à certaines tables dont on modifierait le contenu ? Ou est-ce que définitivement ça ne sert à rien (parce que les transaction ne gèrent pas ce genre d'accès concurrents ou parce que le SGBD s'en charge automatiquement).

J'espère m'être exprimé plus clairement.

Merci de vos réponses.

[estofilo]

Ensuite, j'ai cru comprendre que l'autre intérêt des transactions étaient de gérer les accès concurrents. Ça permettrait donc d'évider que des modifications soient réalisées sur des tables dont on manipulerait déjà le contenu.

Pour un SELECT isolé, le mettre ou non dans une transaction ne changera rien. Le résultat va de toute manière être cohérent, c.a.d que si des modifications ont lieu sur les données dans une autre session alors que le SELECT a déjà démarré, le résultat du SELECT ne reflétera pas ces modifications.

[anrow]

Merci de ta réponse, ton explication me parait tout à fait logique.

Mais j'en viens donc à me poser une autre question.

Par exemple, si des modifications sont effectuées entre 2 SELECT, alors les informations récupérées par le 1er SELECT pourraient ne pas être cohérentes avec celles du 2ème.

Dans ce cas, les transactions ne pourraient-elles pas avoir finalement une utilité lors de l'exécution de plusieurs requêtes SQL "SELECT" ?

[mathieu]

pour plus d'informations sur les différents niveaux d'isolation, regarde là :
http://sqlpro.developpez.com/isolation-transaction/

[anrow]

Merci à toi, Mathieu.

Ton lien m'a aiguillé vers les informations que je cherchais (et m'a montré que je n'avais pas assez poussé mes recherches).

Pour ceux que ça intéresserait, en creusant du coté de la contrainte ACID (Atomicité, Consistance, Isolation et Durabilité) que les SGBD essayent de respecter et plus précisément au niveau de l'Isolation on obtient des réponses à mes questions.

Un petit lien supplémentaire pour un complément d'informations :
Niveau d'isolation des transactions et anomalies transactionnelles

Encore merci.

[Helfima]

juste pour info tous les moteurs de la db pour mysql ne suporte pas les transaction comme MyISAM