SELECT * FROM Client
WHERE id BETWEEN 3 AND 8
FOR UPDATE;
La première session pose un verrou partagé sur les clients 1, 2, 3 et 4.
La seconde session fait trois requêtes de sélection. Toutes les trois concernent les clients 3 à 8 (dont les deux premiers sont
verrouillés).
Requête 1 : ne pose aucun verrou (travaille sur une "photo" de la table et pas sur les vraies données) donc s'effectue
sans souci.
Requête 2 : pose un verrou partagé, ce qui est faisable sur une ligne verrouillée par un verrou partagé. Elle s'effectue
également.
Requête 3 : tente de poser un verrou exclusif, ce qui lui est refusé.
Bien entendu, des requêtes UPDATE ou DELETE (posant des verrous exclusifs) faites par la deuxième session se verraient, elles
aussi, bloquées.
Terminez les transactions des deux sessions (par un rollback ou un commit).
Quant aux requêtes SELECT ... FOR UPDATE posant un verrou exclusif, elles provoqueront exactement les mêmes effets
qu'une requête UPDATE ou DELETE (après tout, un verrou exclusif, c'est un verrou exclusif).
Session 1 :
Code : SQL
START TRANSACTION;
SELECT * FROM Client
WHERE id < 5
FOR UPDATE;
Session 2 :
Code : SQL
START TRANSACTION;
SELECT * FROM Client
WHERE id BETWEEN 3 AND 8;
SELECT * FROM Client
WHERE id BETWEEN 3 AND 8
LOCK IN SHARE MODE;
Cette fois-ci, même la requête SELECT ... LOCK IN SHARE MODE de la seconde session est bloquée (comme le serait
une requête SELECT ... FOR UPDATE, ou une requête UPDATE, ou une requête DELETE).
En résumé
On pose un verrou partagé lorsqu'on fait une requête dans le but de lire des données.
On pose un verrou exclusif lorsqu'on fait une requête dans le but (immédiat ou non) de modifier des données.
Un verrou partagé sur les lignes x va permettre aux autres sessions d'obtenir également un verrou partagé sur les lignes
x, mais pas d'obtenir un verrou exclusif.
Un verrou exclusif sur les lignes x va empêcher les autres sessions d'obtenir un verrou sur les lignes x, qu'il soit partagé
ou exclusif.
En fait, ils portent plutôt bien leurs noms ces verrous !
Partie 5 : Sécuriser et automatiser ses actions
246/414
www.openclassrooms.com
WHERE id BETWEEN 3 AND 8
FOR UPDATE;
La première session pose un verrou partagé sur les clients 1, 2, 3 et 4.
La seconde session fait trois requêtes de sélection. Toutes les trois concernent les clients 3 à 8 (dont les deux premiers sont
verrouillés).
Requête 1 : ne pose aucun verrou (travaille sur une "photo" de la table et pas sur les vraies données) donc s'effectue
sans souci.
Requête 2 : pose un verrou partagé, ce qui est faisable sur une ligne verrouillée par un verrou partagé. Elle s'effectue
également.
Requête 3 : tente de poser un verrou exclusif, ce qui lui est refusé.
Bien entendu, des requêtes UPDATE ou DELETE (posant des verrous exclusifs) faites par la deuxième session se verraient, elles
aussi, bloquées.
Terminez les transactions des deux sessions (par un rollback ou un commit).
Quant aux requêtes SELECT ... FOR UPDATE posant un verrou exclusif, elles provoqueront exactement les mêmes effets
qu'une requête UPDATE ou DELETE (après tout, un verrou exclusif, c'est un verrou exclusif).
Session 1 :
Code : SQL
START TRANSACTION;
SELECT * FROM Client
WHERE id < 5
FOR UPDATE;
Session 2 :
Code : SQL
START TRANSACTION;
SELECT * FROM Client
WHERE id BETWEEN 3 AND 8;
SELECT * FROM Client
WHERE id BETWEEN 3 AND 8
LOCK IN SHARE MODE;
Cette fois-ci, même la requête SELECT ... LOCK IN SHARE MODE de la seconde session est bloquée (comme le serait
une requête SELECT ... FOR UPDATE, ou une requête UPDATE, ou une requête DELETE).
En résumé
On pose un verrou partagé lorsqu'on fait une requête dans le but de lire des données.
On pose un verrou exclusif lorsqu'on fait une requête dans le but (immédiat ou non) de modifier des données.
Un verrou partagé sur les lignes x va permettre aux autres sessions d'obtenir également un verrou partagé sur les lignes
x, mais pas d'obtenir un verrou exclusif.
Un verrou exclusif sur les lignes x va empêcher les autres sessions d'obtenir un verrou sur les lignes x, qu'il soit partagé
ou exclusif.
En fait, ils portent plutôt bien leurs noms ces verrous !
Partie 5 : Sécuriser et automatiser ses actions
246/414
www.openclassrooms.com