d4:c04

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision		 Révision précédente
d4:c04 [2025/10/01 08:57] – [Support des transactions] dthevenotd4:c04 [2025/10/02 16:20] (Version actuelle) – dthevenot
Ligne 63: Ligne 63:
 ===== Support des transactions ===== ===== Support des transactions =====
 Il n'est pas possible d'utiliser les transactions sur n'importe quelle table. Pour les supporter, une table doit être **transactionnelle**, ce qui, avec MySQL, est défini par le moteur de stockage utilisé pour la table.  Il n'est pas possible d'utiliser les transactions sur n'importe quelle table. Pour les supporter, une table doit être **transactionnelle**, ce qui, avec MySQL, est défini par le moteur de stockage utilisé pour la table. 
-Il existe différents moteurs de stockage possibles avec MySQL, dont les plus connus sont **MyISAM** et **InnoDB**. +Il existe différents moteurs de stockage possibles avec MySQL, dont les plus connus sont MyISAM et InnoDB. 
 Nous n’avons utilisé que des tables créées avec le moteur InnoDB, ce qui tombe plutôt bien car en effet  Nous n’avons utilisé que des tables créées avec le moteur InnoDB, ce qui tombe plutôt bien car en effet 
 :  : 
-  * les tables MyISAM sont non transactionnelles, donc ne supportent pas les transactions  +  * les tables **MyISAM** sont **non transactionnelles**, donc ne supportent pas les transactions  
-  * les tables InnoDB sont transactionnelles, donc supportent les transactions. +  * les tables **InnoDB** sont **transactionnelles**, donc supportent les transactions. 
        
-===== Syntaxe et utilisation ===== +===== Validation implicite et commandes non annulables =====
-  +
-==== Vocabulaire ==== +
-  +
-Lorsque l'on valide les requêtes d'une transaction, on dit aussi que l'on **commite** les changements. À l'inverse, l'annulation des requêtes s'appelle un **rollback**.  +
-==== Comportement par défaut ==== +
-  +
-Vous l'aurez compris, par défaut, MySQL ne travaille pas avec les transactions. Chaque requête effectuée est directement commitée (validée). On ne peut pas revenir en arrière. On peut donc considérer que chaque requête constitue une transaction qui est automatiquement commitée. Par défaut, MySQL est donc en mode "autocommit".   +
-Pour quitter ce mode, il suffit de lancer la requête suivante :  +
- +
-<code>SET autocommit=0; </code> +
- +
-Une fois que vous n'êtes plus en autocommit, chaque modification de donnée devra être commitée pour prendre effet.  +
- +
-Tant que vos modifications ne sont pas validées, vous pouvez à tout moment les annuler (faire un rollback). +
-  +
-<bootnote>Trouvez dans votre outil de gestion de bases de données dans quel menu voir si l’autocommit est activé</bootnote>  +
-==== Commandes essentielles ==== +
-<bootnote learn> +
-  * START TRANSACTION; → démarre une transaction +
-  * COMMIT; → valide les modifications +
-  * ROLLBACK; → annule les modifications +
-  * SAVEPOINT nom; → crée un point intermédiaire +
-  * ROLLBACK TO nom; → annule seulement jusqu’au point donné +
-</bootnote> +
- +
- +
-===== D4-A05 : Application des transactions sur la base de données Biblio ===== +
-  +
-==== 1) Validation/annulation de requêtes ==== +
-  +
-Exécuter les requêtes suivantes dans une même fenêtre d’exécution : +
-<code>  +
-SET autocommit=0;  +
-INSERT INTO genre (nomGenre) VALUES('test');  +
-</code> +
-<bootnote question> Le genre « test » a-t-il été ajouté à la table genre ? Pourquoi ?  </bootnote>  +
- +
-Maintenant exécuter les 3 requêtes suivantes dans une même fenêtre d’exécution : +
-<code>  +
-SET autocommit=0;  +
-INSERT INTO genre (nomGenre) VALUES('test1');  +
-Commit ;  +
-</code> +
-<bootnote question>Le genre « test » a-t-il été ajouté à la table genre ? Pourquoi ?</bootnote> +
-  +
-Exécuter les requêtes suivantes dans une même fenêtre d’exécution : +
-<code>  +
-INSERT INTO genre (nomGenre) VALUES('test2'); +
-SELECT * FROM genre;  +
-</code>  +
-<bootnote question>Le genre « test » a-t-il été ajouté à la table genre ? Pourquoi ?</bootnote> +
-  +
-<bootnote>Le fait de faire SET autocommit = 0; n'est valable que pour la session courante. Or, en ouvrant une nouvelle connexion ou une nouvelle fenêtre d’exécution, vous créez une nouvelle session.</bootnote>  +
-  +
-==== 2) Visibilité des changements non commités. ==== +
-  +
-Exécuter les requêtes suivantes dans une même fenêtre d’exécution :  +
-<code>  +
-SET autocommit=0;  +
-INSERT INTO genre (nomGenre) VALUES('test3');  +
-SELECT * FROM genre ; +
-</code>   +
-Ensuite, tout en laissant ce client MySQL ouvert, ouvrez-en un deuxième. Connectez-vous comme d'habitude à la base de données biblio. Vous avez maintenant deux sessions ouvertes. +
-  +
-<bootnote question>Allez voir le contenu de la table genre. Comparez les 2 tables genre. Que constatez-vous ? Expliquez ce résultat.</bootnote>  +
-  +
-La table genre n’a pas changé. Les changements non commités ne sont donc pas visibles à l'extérieur de la transaction qui les a faits. En particulier, une autre session n'a pas accès à ces changements.  +
- +
-==== Démarrer explicitement une transaction ==== +
-  +
-En désactivant le mode autocommit, en réalité, on démarre une transaction. Et chaque fois que l'on fait un rollback ou un commit (ce qui met fin à la transaction), une nouvelle transaction est créée automatiquement, et ce tant que la session est ouverte.  +
- +
-Il est également possible de démarrer explicitement une transaction, auquel cas on peut laisser le mode autocommit activé, et décider au cas par cas des requêtes qui doivent être faites dans une transaction.  +
- +
-Nous sommes toujours en mode autocommit activé, pour démarrer une transaction, il suffit de lancer la commande suivante :  +
-<code> START TRANSACTION; </code>  +
- +
-Avec MySQL, il est également possible de démarrer une transaction avec BEGIN ou BEGIN WORK. Cependant, il est conseillé d'utiliser plutôt START TRANSACTION, car il s'agit de la commande SQL standard.  +
- +
-Une fois la transaction ouverte, les requêtes devront être validées pour prendre effet. Attention au fait qu'un COMMIT ou un ROLLBACK met fin automatiquement à la transaction, donc les commandes suivantes seront à nouveau commitées automatiquement si une nouvelle transaction n'est pas ouverte.  +
-   +
-=== Exemples de transactions en mode autocommit (à exécuter en 1 fois) : === +
-<code>   +
-start transaction;  +
-INSERT INTO genre (nomGenre) VALUES('testTransation'); SELECT * FROM genre; rollback;  +
-SELECT * FROM genre;  +
-</code>   +
- +
-<bootnote question> +
-  * Comparez les 2 résultats des « SELECT * ». Que constatez-vous ? Expliquez ce résultat.  +
-  * En utilisant la transaction, comment faire pour que le genre testTransaction soit effectivement inséré dans la table genre ? +
-</bootnote>  +
-  +
-==== Jalon de transaction ==== +
-  +
-Lorsque l'on travaille dans une transaction et que l'on constate que certaines requêtes posent problème, on n'a pas toujours envie de faire un rollback depuis le début de la transaction, annulant toutes les requêtes alors qu'une partie aurait pu être validée. Il n'est pas possible de démarrer une transaction à l'intérieur d'une transaction. Par contre, on peut poser des jalons de transaction. Il s'agit de points de repère qui permettent d'annuler toutes les requêtes exécutées depuis ce jalon, et non toutes les requêtes de la transaction.  +
- +
-=== Syntaxe === +
-  +
-Trois nouvelles commandes suffisent pour pouvoir utiliser pleinement les jalons :  +
-<code>  +
-SAVEPOINT nom_jalon;   +
--- Crée un jalon avec comme nom "nom_jalon"  +
-ROLLBACK [WORK] TO [SAVEPOINT] nom_jalon;   +
--- Annule les requêtes exécutées depuis le jalon "nom_jalon", WORK et SAVEPOINT ne sont pas obligatoires  +
-RELEASE SAVEPOINT nom_jalon;   +
--- Retire le jalon "nom_jalon" (sans annuler, ni valider les requêtes faites depuis)  +
-</code>  +
- +
-__Exemple :__ exécutez les requêtes suivantes en 1 fois.  +
-<code>  +
-START TRANSACTION;  +
-insert into genre (nomGenre) values('testJalon1'); SAVEPOINT jalon1;  +
-insert into genre (nomGenre) values('testJalon2'); ROLLBACK TO SAVEPOINT jalon1;  +
-insert into genre (nomGenre) values('testJalon3');  +
-COMMIT;  +
-</code>  +
- +
-On n'utilise qu'une seule transaction, on valide à la fin, et pourtant, la seconde insertion n'a pas été faite finalement, puisqu'elle a été annulée grâce au jalon. Seuls les genres « testjalon1 » et « testJalon3 » existent.  +
- +
-==== autres exercices ==== +
-Ces exercices permettent de manipuler les transactions dans des cas concrets. +
-  * Exercice 1 : Insérer un nouveau genre de livre +
-Table : genre(idGenre, nomGenre) +
-  - 1. SET autocommit=0; +
-  - 2. INSERT INTO genre (nomGenre) VALUES('Science-fiction'); +
-  - 3. Vérifiez le contenu de la table avant COMMIT puis après COMMIT. +
- +
-Correction Exercice 1 +
-<code> +
-SET autocommit=0; +
-INSERT INTO genre (nomGenre) VALUES('Science-fiction'); +
-SELECT * FROM genre; -- L’enregistrement n’est pas encore visible après fermeture de session +
-COMMIT; -- Rend le changement définitif +
-</code> +
- +
-  * Exercice 2 : Transfert bancaire +
-  - Créer une table compte(id, nom, solde). +
-  - Effectuer un transfert de 200 € du compte A vers le compte B avec une transaction. +
-  - Si une mise à jour échoue, tout doit être annulé. +
- +
-Correction Exercice 2 +
-<code> +
-START TRANSACTION; +
-UPDATE compte SET solde = solde - 200 WHERE id = 1; +
-UPDATE compte SET solde = solde + 200 WHERE id = 2; +
-COMMIT; +
--- Si problème : ROLLBACK; +
-</code> +
- +
-  * Exercice 3 : SAVEPOINT +
-  - Créer plusieurs insertions dans une table avec un SAVEPOINT. +
-  - Annuler seulement une partie des requêtes. +
- +
-Correction Exercice 3 +
-<code> +
-START TRANSACTION; +
-INSERT INTO genre (nomGenre) VALUES('Test1'); +
-SAVEPOINT s1; +
-INSERT INTO genre (nomGenre) VALUES('Test2'); +
-ROLLBACK TO s1; +
-INSERT INTO genre (nomGenre) VALUES('Test3'); +
-COMMIT; +
-</code> +
-  * Exercice 4 : Concurrence +
-Ouvrir deux sessions MariaDB : +
-  * - Dans la première, insérer un enregistrement sans COMMIT. +
-  * - Dans la deuxième, vérifier que l’insertion n’est pas visible. +
- +
-<del> +
-=== Validation implicite et commandes non annulables ===+
    
 Vous savez déjà que, pour terminer une transaction, il faut utiliser les commandes COMMIT ou ROLLBACK, selon que l'on veut valider les requêtes ou les annuler.  Vous savez déjà que, pour terminer une transaction, il faut utiliser les commandes COMMIT ou ROLLBACK, selon que l'on veut valider les requêtes ou les annuler. 
Ligne 248: Ligne 77:
 Par ailleurs, ces commandes ne peuvent pas être annulées par un ROLLBACK.  Par ailleurs, ces commandes ne peuvent pas être annulées par un ROLLBACK. 
  
-== Commandes DDL ==+==== Commandes DDL ====
    
 Toutes les commandes qui créent, modifient, suppriment des objets dans la base de données valident implicitement les transactions. Ces commandes forment ce que l'on appelle les requêtes DDL, pour Data Definition Langage.  Toutes les commandes qui créent, modifient, suppriment des objets dans la base de données valident implicitement les transactions. Ces commandes forment ce que l'on appelle les requêtes DDL, pour Data Definition Langage. 
Ligne 258: Ligne 87:
   * De manière générale, tout ce qui influe sur la structure de la base de données, et non sur les données elles-mêmes.    * De manière générale, tout ce qui influe sur la structure de la base de données, et non sur les données elles-mêmes. 
  
-== Utilisateurs ==+==== Utilisateurs ====
    
 La création, la modification et la suppression d'utilisateurs provoquent aussi une validation implicite.  La création, la modification et la suppression d'utilisateurs provoquent aussi une validation implicite. 
  
-=== Transactions et verrous ===+===== Syntaxe et utilisation =====
    
-Il n’est pas possible d'imbriquer des transactions, donc d'avoir une transaction à l'intérieur d'une transaction. En fait, la commande START TRANSACTION  provoque également une validation implicite si elle est exécutée à l'intérieur d'une transaction. +==== Vocabulaire ==== 
 +  
 +Lorsque l'on valide les requêtes d'une transaction, on dit aussi que l'on **commite** les changements. À l'inverse, l'annulation des requêtes s'appelle un **rollback**.  
 +==== Comportement par défaut ==== 
 +  
 +Par défaut, MySQL ne travaille pas avec les transactions. Chaque requête effectuée est directement commitée (validée). On ne peut pas revenir en arrière. On peut donc considérer que chaque requête constitue une transaction qui est automatiquement commitée. Par défaut, MySQL est donc en mode "autocommit".   
 +Pour quitter ce mode, il suffit de lancer la requête suivante : 
  
-Le fait d'activer le mode autocommit (s'il n'était pas déjà activé) a le même effet. +<code>SET autocommit=0; </code>
  
-La création et suppression de verrous de table clôturent aussi une transaction en la validant implicitement (voir partie suivante).  +Une fois que vous n'êtes plus en autocommit, chaque modification de donnée devra être commitée pour prendre effet.  
-=== Chargement de données ===+ 
 +Tant que vos modifications ne sont pas validées, vous pouvez à tout moment les annuler (faire un rollback).
    
-Enfin, le chargement de données avec LOAD DATA  provoque également une validation implicite.</del> +<bootnote>Trouvez dans votre outil de gestion de bases de données dans quel onglet voir si l’autocommit est activé</bootnote> 
  
-<bootnote learn> +[[d4:A05]]
-En résumé  +
-  * Les transactions permettent de grouper plusieurs requêtes, lesquelles seront validées (COMMIT) ou annulées (ROLLBACK) toutes en même temps.  +
-  * Tous les changements de données (insertion, suppression, modification) faits par les requêtes à l'intérieur d'une transaction sont invisibles pour les autres sessions tant que la transaction n'est pas validée.  +
-  * Les transactions permettent d'exécuter un traitement nécessitant plusieurs requêtes en une seule fois, ou de l'annuler complètement si une des requêtes pose problème ou si la transaction est interrompue.  +
-  * Certaines commandes SQL provoquent une validation implicite des transactions, notamment toutes les commandes DDL, c'est-à-dire les commandes qui créent, modifient ou suppriment des objets dans la base de données (tables, index…).  +
-  * Les critères ACID sont les critères qu'un système appliquant les transactions doit respecter pour être fiable : Atomicité, Cohérence, Isolation, Durabilité. +
-</bootnote> +
  
  • d4/c04.1759301875.txt.gz
  • Dernière modification : 2025/10/01 08:57
  • de dthevenot