Exécuter les requêtes suivantes dans une même fenêtre d’exécution :

SET autocommit=0; 
INSERT INTO genre (nomGenre) VALUES('test0'); 

Maintenant exécuter les 3 requêtes suivantes dans une même fenêtre d’exécution :

SET autocommit=0; 
INSERT INTO genre (nomGenre) VALUES('test1'); 
Commit ; 

Exécuter les requêtes suivantes dans une même fenêtre d’exécution :

INSERT INTO genre (nomGenre) VALUES('test2');
SELECT * FROM genre; 

Exécuter les requêtes suivantes dans une même fenêtre d’exécution :

SET autocommit=0; 
INSERT INTO genre (nomGenre) VALUES('test3'); 
SELECT * FROM genre ;

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.

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.

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 :

 START TRANSACTION; 

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.

START TRANSACTION; 
INSERT INTO genre (nomGenre) VALUES('testTransaction'); 
SELECT * FROM genre; 
ROLLBACK; 
SELECT * FROM genre; 

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.

Trois nouvelles commandes suffisent pour pouvoir utiliser pleinement les jalons, voici la SYNTAXE :

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) 

Exemple : exécutez les requêtes suivantes en 1 fois.

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; 

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.

1. Mettre en œuvre les transactions dans des cas simples.
2. Manipuler COMMIT et ROLLBACK.

1. Créer une table compte(id, nom, solde).
2. Insérer quelques comptes.
3. 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é.

1. Effectuer des transferts multiples avec un rollback partiel.

1. Simuler deux sessions MariaDB (deux terminaux).
2. Montrer l’effet d’un COMMIT tardif sur les lectures concurrentes.