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:36] – [Jalon de transaction] dthevenotd4:a05 [2025/10/01 14:52] (Version actuelle) – [Exercices d'application] dthevenot
Ligne 93: Ligne 93:
 </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 == 
-Correction Exercice 2 +  - Effectuer des transferts multiples avec un rollback partiel. 
-<code> +== Concurrence == 
-START TRANSACTION; +  - Simuler deux sessions MariaDB (deux terminaux). 
-UPDATE compte SET solde = solde - 200 WHERE id = 1; +  - Montrer l’effet d’un COMMIT tardif sur les lectures concurrentes.
-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.  +
- +
-Ç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>  
 ==== Commandes essentielles ==== ==== Commandes essentielles ====
 <bootnote learn> <bootnote learn>
  • d4/a05.1759322173.txt.gz
  • Dernière modification : 2025/10/01 14:36
  • de dthevenot