d4:a05

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:a05 [2025/10/01 14:29] – [Démarrer explicitement une transaction] dthevenotd4:a05 [2025/10/01 14:52] (Version actuelle) – [Exercices d'application] dthevenot
Ligne 4: Ligne 4:
    
 Exécuter les requêtes suivantes dans une même fenêtre d’exécution : Exécuter les requêtes suivantes dans une même fenêtre d’exécution :
-<code>  +<code>SET autocommit=0; 
-SET autocommit=0; +
 INSERT INTO genre (nomGenre) VALUES('test0');  INSERT INTO genre (nomGenre) VALUES('test0'); 
 </code> </code>
Ligne 11: Ligne 10:
  
 Maintenant exécuter les 3 requêtes suivantes dans une même fenêtre d’exécution : Maintenant exécuter les 3 requêtes suivantes dans une même fenêtre d’exécution :
-<code>  +<code>SET autocommit=0; 
-SET autocommit=0; +
 INSERT INTO genre (nomGenre) VALUES('test1');  INSERT INTO genre (nomGenre) VALUES('test1'); 
 Commit ;  Commit ; 
Ligne 19: Ligne 17:
    
 Exécuter les requêtes suivantes dans une même fenêtre d’exécution : Exécuter les requêtes suivantes dans une même fenêtre d’exécution :
-<code>  +<code>INSERT INTO genre (nomGenre) VALUES('test2');
-INSERT INTO genre (nomGenre) VALUES('test2');+
 SELECT * FROM genre;  SELECT * FROM genre; 
 </code>  </code> 
Ligne 30: Ligne 27:
    
 Exécuter les requêtes suivantes dans une même fenêtre d’exécution :  Exécuter les requêtes suivantes dans une même fenêtre d’exécution : 
-<code>  +<code>SET autocommit=0; 
-SET autocommit=0; +
 INSERT INTO genre (nomGenre) VALUES('test3');  INSERT INTO genre (nomGenre) VALUES('test3'); 
 SELECT * FROM genre ; SELECT * FROM genre ;
Ligne 60: Ligne 56:
        
 === Exemples de transactions en mode autocommit (à exécuter en 1 fois) : === === Exemples de transactions en mode autocommit (à exécuter en 1 fois) : ===
-<code>   +<code>START TRANSACTION; 
-START TRANSACTION; +
 INSERT INTO genre (nomGenre) VALUES('testTransaction');  INSERT INTO genre (nomGenre) VALUES('testTransaction'); 
 SELECT * FROM genre;  SELECT * FROM genre; 
Ligne 69: Ligne 64:
  
 <bootnote question> <bootnote question>
-  * Comparez les 2 résultats des « SELECT * ». Que constatez-vous ? Expliquez ce résultat.  +  - 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 ?+  - En utilisant la transaction, comment faire pour que le genre testTransaction soit effectivement inséré dans la table genre ?
 </bootnote>  </bootnote> 
    
Ligne 79: Ligne 74:
 === Syntaxe === === Syntaxe ===
    
-Trois nouvelles commandes suffisent pour pouvoir utiliser pleinement les jalons :  +Trois nouvelles commandes suffisent pour pouvoir utiliser pleinement les jalons, voici la **SYNTAXE** :  
-<code>  +<code>SAVEPOINT nom_jalon;  
-SAVEPOINT nom_jalon;  +
 -- Crée un jalon avec comme nom "nom_jalon"  -- Crée un jalon avec comme nom "nom_jalon" 
 ROLLBACK [WORK] TO [SAVEPOINT] nom_jalon;   ROLLBACK [WORK] TO [SAVEPOINT] nom_jalon;  
Ligne 90: Ligne 84:
  
 __Exemple :__ exécutez les requêtes suivantes en 1 fois.  __Exemple :__ exécutez les requêtes suivantes en 1 fois. 
-<code>  +<code>START TRANSACTION;  
-START TRANSACTION;  +insert into genre (nomGenre) values('testJalon1');  
-insert into genre (nomGenre) values('testJalon1'); SAVEPOINT jalon1;  +SAVEPOINT jalon1;  
-insert into genre (nomGenre) values('testJalon2'); ROLLBACK TO SAVEPOINT jalon1; +insert into genre (nomGenre) values('testJalon2');  
 +ROLLBACK TO SAVEPOINT jalon1; 
 insert into genre (nomGenre) values('testJalon3');  insert into genre (nomGenre) values('testJalon3'); 
 COMMIT;  COMMIT; 
 </code>  </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.  +<bootnote question>Quels genres ont été ajoutés, pourquoi ?</bootnote>  
- +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 ==== +==== Exercices d'application ==== 
-Ces exercices permettent de manipuler les transactions dans des cas concrets. +=== Objectifs === 
-  * Exercice 1 : Insérer un nouveau genre de livre +  - Mettre en œuvre les transactions dans des cas simples. 
-Table : genre(idGenre, nomGenre) +  - Manipuler COMMIT et ROLLBACK. 
-  - 1. SET autocommit=0; +=== Exercice 1 : gestion de comptes bancaires ===
-  - 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).   - Créer une table compte(id, nom, solde).
-  - Effectuer un transfert de 200 € du compte A vers le compte B avec une transaction. +  - Insérer quelques comptes. 
-  - Si une mise à jour échoue, tout doit être annulé.+  - Ecrire les commandes SQL pour effectuer un transfert de 200 € du compte A vers le compte B avec une transaction -> Si une mise à jour échoue, tout doit être annulé. 
 +== Utilisation de SAVEPOINT == 
 +  - Effectuer des transferts multiples avec un rollback partiel. 
 +== Concurrence == 
 +  - Simuler deux sessions MariaDB (deux terminaux). 
 +  - Montrer l’effet d’un COMMIT tardif sur les lectures concurrentes.
  
-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 +==== Commandes essentielles ==== 
-<code> +<bootnote learn> 
-START TRANSACTION; +  * START TRANSACTION; → démarre une transaction 
-INSERT INTO genre (nomGenre) VALUES('Test1'); +  * COMMIT; → valide les modifications 
-SAVEPOINT s1; +  * ROLLBACK; → annule les modifications 
-INSERT INTO genre (nomGenre) VALUES('Test2'); +  * SAVEPOINT nom; → crée un point intermédiaire 
-ROLLBACK TO s1; +  * ROLLBACK TO nom; → annule seulement jusqu’au point donné 
-INSERT INTO genre (nomGenre) VALUES('Test3'); +</bootnote>
-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.  +
- +
-Ça, c'est la manière classique et recommandée. Mais il faut savoir qu'un certain nombre d'autres commandes auront aussi pour effet de clôturer une transaction. Et pas seulement de la clôturer, mais également de valider toutes les requêtes qui ont été faites dans cette transaction, exactement comme si vous utilisiez COMMIT.  +
- +
-Par ailleurs, ces commandes ne peuvent pas être annulées par un ROLLBACK.  +
- +
-== 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.  +
-Cela comprend donc :  +
-  * La création et suppression de bases de données : CREATE DATABASE, DROP DATABASE  ;  +
-  * La création, modification, suppression de tables : CREATE TABLE, ALTER TABLE, RENAME TABLE, DROP TABLE  ;  +
-  * La création, modification, suppression d'index : CREATE INDEX, DROP INDEX  ;  +
-  * La création d'objets comme les procédures stockées, les vues, etc., dont nous parlerons plus tard.  +
-  * 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 == +
-  +
-La création, la modification et la suppression d'utilisateurs provoquent aussi une validation implicite.  +
- +
-=== Transactions et verrous === +
-  +
-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.  +
- +
-Le fait d'activer le mode autocommit (s'il n'était pas déjà activé) a le même effet.  +
- +
-La création et suppression de verrous de table clôturent aussi une transaction en la validant implicitement (voir partie suivante).  +
-=== Chargement de données === +
-  +
-Enfin, le chargement de données avec LOAD DATA  provoque également une validation implicite.</del> +
  
 +==== A retenir ====
 <bootnote learn> <bootnote learn>
-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.    * 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.    * 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. 
Ligne 191: Ligne 128:
   * 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é.   * 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>  </bootnote> 
- 
  • d4/a05.1759321772.txt.gz
  • Dernière modification : 2025/10/01 14:29
  • de dthevenot