paye)
SELECT id, 8, NOW(), 735.00, 1
FROM Client
WHERE email = 'jean.dupont@email.com';
COMMIT;
Et M. Durant jette également son dévolu sur Bagherra (qui est décidément très très mignon) !
Code : SQL
INSERT INTO Client (nom, prenom, email)
VALUES ('Durant', 'Philippe', 'phidu@email.com');
INSERT INTO Adoption (client_id, animal_id, date_reservation, prix,
paye)
VALUES (LAST_INSERT_ID(), 8, NOW(), 735.00, 0);
L'insertion dans Client fonctionne mais l'insertion dans Adoption pose problème :
Code : Console
ERROR 1062 (23000): Duplicate entry '8' for key 'ind_uni_animal_id'
Et pour cause : Bagherra vient d'être adopté, à l'instant.
Furieux, M. Durant s'en va, et l'élevage a perdu un client. Il ne reste plus qu'à annuler sa transaction.
C'est pour éviter ce genre de situation qu'il vaut parfois mieux mettre un verrou exclusif sur une sélection. Si l'on sait que cette
sélection sert à déterminer quels changements vont être faits, ce n'est pas la peine de laisser quelqu'un d'autre lire des
informations qui cesseront d'être justes incessamment sous peu.
Niveaux d'isolation
Nous avons vu que par défaut :
lorsque l'on démarre une transaction, la session prend une photo des tables, et travaille uniquement sur cette photo
(donc sur des données potentiellement périmées) tant qu'elle ne pose pas un verrou ;
les requêtes SELECT ne posent pas de verrous si l'on ne le demande pas explicitement ;
les requêtes SELECT ... LOCK IN SHARE MODE, SELECT ... FOR UPDATE, DELETE et UPDATE posent
un verrou de clé suivante (sauf dans le cas d'une recherche sur index unique, avec une valeur unique).
Ce comportement est défini par le niveau d'isolation des transactions.
Syntaxe
Pour définir le niveau d'isolation des transactions, on utilise la requête suivante :
Code : SQL
SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL { READ
UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE }
Le mot-clé GLOBAL définit le niveau d'isolation pour toutes les sessions MySQL qui seront créées dans le futur. Les
sessions existantes ne sont pas affectées.
SESSION définit le niveau d'isolation pour la session courante.
Si l'on ne précise ni GLOBAL, ni SESSION, le niveau d'isolation défini ne concernera que la prochaine transaction que
l'on ouvrira dans la session courante.
Partie 5 : Sécuriser et automatiser ses actions
252/414
www.openclassrooms.com
SELECT id, 8, NOW(), 735.00, 1
FROM Client
WHERE email = 'jean.dupont@email.com';
COMMIT;
Et M. Durant jette également son dévolu sur Bagherra (qui est décidément très très mignon) !
Code : SQL
INSERT INTO Client (nom, prenom, email)
VALUES ('Durant', 'Philippe', 'phidu@email.com');
INSERT INTO Adoption (client_id, animal_id, date_reservation, prix,
paye)
VALUES (LAST_INSERT_ID(), 8, NOW(), 735.00, 0);
L'insertion dans Client fonctionne mais l'insertion dans Adoption pose problème :
Code : Console
ERROR 1062 (23000): Duplicate entry '8' for key 'ind_uni_animal_id'
Et pour cause : Bagherra vient d'être adopté, à l'instant.
Furieux, M. Durant s'en va, et l'élevage a perdu un client. Il ne reste plus qu'à annuler sa transaction.
C'est pour éviter ce genre de situation qu'il vaut parfois mieux mettre un verrou exclusif sur une sélection. Si l'on sait que cette
sélection sert à déterminer quels changements vont être faits, ce n'est pas la peine de laisser quelqu'un d'autre lire des
informations qui cesseront d'être justes incessamment sous peu.
Niveaux d'isolation
Nous avons vu que par défaut :
lorsque l'on démarre une transaction, la session prend une photo des tables, et travaille uniquement sur cette photo
(donc sur des données potentiellement périmées) tant qu'elle ne pose pas un verrou ;
les requêtes SELECT ne posent pas de verrous si l'on ne le demande pas explicitement ;
les requêtes SELECT ... LOCK IN SHARE MODE, SELECT ... FOR UPDATE, DELETE et UPDATE posent
un verrou de clé suivante (sauf dans le cas d'une recherche sur index unique, avec une valeur unique).
Ce comportement est défini par le niveau d'isolation des transactions.
Syntaxe
Pour définir le niveau d'isolation des transactions, on utilise la requête suivante :
Code : SQL
SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL { READ
UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE }
Le mot-clé GLOBAL définit le niveau d'isolation pour toutes les sessions MySQL qui seront créées dans le futur. Les
sessions existantes ne sont pas affectées.
SESSION définit le niveau d'isolation pour la session courante.
Si l'on ne précise ni GLOBAL, ni SESSION, le niveau d'isolation défini ne concernera que la prochaine transaction que
l'on ouvrira dans la session courante.
Partie 5 : Sécuriser et automatiser ses actions
252/414
www.openclassrooms.com