Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
LA CONCURRENCE
ObjectifsLes mécanismes de verrouillageLe verrouillage sous OracleExercices
2
1. ObjectifsPermettre l’exécution simultanée d’un grand
nombre de transactionsRégler les conflits lecture / écritureGarder de très bonne performanceÉviter les blocages
3
Récapitulatif sur les transactions
Transaction : • possibilité d'exécuter intégralement un bloc
d'opérations, • ou alors défaire les modifications si abort
En théorie :• les transactions sont effectuées en séquence, la
consistance des données est garantie
En pratique :• l'exécution de transactions en séquence est très peu
efficace• temps d'attente peut devenir insupportable
4
Exemples
Opérations bancaires• transactions séquentielles empêchent deux
utilisateurs de travailler sur leurs comptes
Réservation de billets d'avion• la réservation de toutes les places de l'avion est
bloquée tant qu'une transaction d'achat ne finit pas (entrée données utilisateurs, payement, etc.)
Opérations de longue durée• transaction pour créer le rapport financier d'une
banque lors des 12 derniers mois.
5
Solution : relaxer les contraintes
Afin d'optimiser l'exécution des transactions, nous allons permettre l'exécution concurrente de certaines opérations
• permettre le travail concurrent sur des données distincts
• permettre un contrôle de concurrence sur les données partagées
6
Deux transactions qui effectuent des operations sur un compte A
1.lire (A)2.A=A+1003.écrire (A)
Dans certaines conditions les transactions peuvent coexister sans aucun probleme
Transactions Parallèles
1.lire (A)2.si a < 50 trigger
ALERT
7
L'application Bar à Bière PAUL
1.SELECT MAX(prix) FROM BarÀBière WHERE bar='Jo'
2.SELECT MIN(prix) FROM BarÀBière WHERE bar='Jo'
Problèmes d'Incohérence
FRED1.DELETE FROM BarÀBière
WHERE bar='Jo'2.INSERT INTO BarÀBière
VALUES(‘Jo’, ‘Kwak’, 3.50);
Jo
Jo
Moe
Heinekein
Budweiser
Duffy
2,50
3.00
5,00
8
Les problèmes de concurrence
Perte de mises à jour• Lorsqu'une transaction écrase les valeurs écrits par
une autre transaction
1.lire (A)
3.A=A+250
4.écrire (A)
1.lire (A)
2.A=A+250
3.écrire (A)
BaseA=10
A=260A=110
9
Les problèmes de concurrence
Lecture impropre• Lorsqu'une transaction accède à des valeurs qui
sont modifiées et postérieurement rétractées
1.
1.lire (A)
1.lire (A)2.A=A+2503.écrire (A)
4.Rollback
BaseA=10
A=260A=10
10
Les problèmes de concurrence
Lecture non reproductibles• Lorsqu'une valeur est modifiée entre deux lectures
différentes
1.lire (A)1.lire (A)2.A=A+2503.écrire (A)
BaseA=10
A=2602.lire (A)
11
2. Les mécanismes de verrouillage
Idée : identifier les accès concurrents à des ressources et signaler à travers un verrou que ce donnée pourra être modifiée
• empêche certaines transactions d'avancer avant qu'une donnée soit mise à jour
• limite les dégâts (effet domino) lors des rollbacks
12
Exemple d'utilisation de verrousT1 T2
lock(c1)
read(c1) for update
c1:=c1-m1 T2 attend la libération de c1
écrire(c1) (demande accès pour update de c1)
lock(c2) "
read(c2) for update "
c2:=c2+m1 "
écrire(c2) "
unlock(c1,c2) lock(c1)
read(c1) for update
c1:=c1-m2
écrire(c1)
lock(c3)
read(c3) for update
c3:=c3+m2
écrire(c3)
unlock(c1,c3)
13
Verrouillage binaire
Principe :
• les données sont marquées d'un verrou
0 – libre1 – verrouillé
• une opération ne peut se produire si elle a préalablement acquis le verrou sur un élément X
• si le verrou est à 1 la transaction doit attendre
14
Verrouillage binaire
Désavantages
• le verrouillage binaire est trop restrictive
• parfois certaines transactions ne font que lire des données
T1 T2lire (taux) lire(taux)A=A*taux B=B*tauxécrire(A) écrire(B)
15
Verrouillage binaire
Avec un verrouillage binaire
T1 T2verrouiller(taux) attend libération de tauxlire(taux)A=A*tauxécrire(A)libérer(taux) verrouiller(taux) lire(taux) B=B*taux écrire(B) libérer(taux)
16
Verrouillage partagée X exclusive
Principe :
• les données sont marquées d'un verrou
0 – libre s – partagéex - exclusive
• un verrou partagée permet la lecture concurrente des données, mais empêche l'écriture sur les éléments
17
Problèmes de concurrence
Interblocage (deadlock)• chaque transaction T d’un ensemble de n (n ≥ 2)
transactions attend une donnée verrouillée par une autre transaction T’ de l’ensemble
T1 T2
lock(c1)
read(c1)
c1:=c1+m lock(c2)
écrire(c1) read(c2)
c2:=c2+n
T1 attend libération de c2 écrire(c2)
" T2 attend libération de c1
" "
" "
18
Solution pour le deadlock
Graphes d'attente de ressources • le système maintient un graphe avec la liste de
ressources en attente des transactions• chaque fois que le système détecte un cycle il tue
une ou plusieurs transactions afin de débloquer l'exécution
T1 T2
T2
T1 T3
19
Niveaux d'Isolation
Le standard SQL définit 4 niveaux d'isolation pour les verrous
SERIALIZABLE REPEATABLE READ READ COMMITTED
READ UNCOMMITTED
consistance fléxibilité /performance
20
Serializable
Les transactions sont effectuées les unes après les autres, de manière séquentielle• évite tout problème d'inconsistance des données• très contraignant pour la performance
Exemple – Bar à bières
PAUL1.SELECT MAX(prix) FROM
BarÀBière WHERE bar='Jo'2.SELECT MIN(prix) FROM
BarÀBière WHERE bar='Jo'
FRED1.DELETE FROM BarÀBière
WHERE bar='Jo'2.INSERT INTO BarÀBière
VALUES(‘Jo’, ‘Kwak’, 3.50);
21
Repeatable read
Seulement les données valides seront accessibles• évite les lectures non reproductibles• l'application peut avoir accès à des nouveaux tuples
ou des tuples qui ont été effacés
Exemple – Bar à bièresordre d'exécution : (max)(del)(ins)(min)
• max voit 2,50 et 3,00min voit 2,50, 3,00 et aussi 3,50
22
Read committed
Seulement les données valides seront lues, mais des lectures successives peuvent rendre des valeurs (validées) différentes• permet de voir les mises à jour des autres processus
Exemple – Bar à bièresordre d'exécution :
(max)(del)(ins)(commit)(min)• max voit 2,50 et 3,00
min voit 3,50
23
Read uncommitted
Les transactions ont accès aux valeurs dès leur modification• même si les valeurs ne sont pas validées (abort)
Exemple – Bar à bièresordre d'exécution : (max)(del)(ins)(abort)(min)
• max voit 2,50 et 3,00min voit 3,50
24
Verrouillage et niveau de granularité
Le verrouillage peut s'appliquer à des différents niveaux de la base• attributs d'un tuple• un ou plusieurs tuples• une ou plusieurs tables• toute la base
Le plus étendu le verrou le plus contraignant est l'accès des transactions concurrentes• les transactions restent à l'attente des la libération
des verrous
25
Verrouillage et niveau de granularité
attributs d'un tupleun ou plusieurs tuplesune ou plusieurs tables
toute la base
Il est important de choisir la granularité la plus adaptée à chaque type d'accès aux données
accèsconcurrent
complexité
26
3. Les verrouillages sous Oracle
Oracle implémente par défaut un mécanisme d'accès consistant en mode lecture• ready consistency• une transaction n'a accès qu'aux données validées
lorsqu'elle a commencé (Isolation)• les données modifiées après le début d'une
transaction ne sont pas visibles
a=5
a=5
a=a+10
27
Les verrouillages sous Oracle
Ce mécanisme implémente un verrouillage automatique lors des mises à jour• la première transaction à vouloir modifier une
donnée pose un verrou, les autres attendent la fin de la transaction
Possibilité de créer une transaction spéciale• accès concurrent en lecture seule• permet des lectures non reproductibles SET TRANSACTION READ ONLY ... COMMIT
28
L'isolation sous Oracle
Oracle supporte seulement deux types d'isolation entre les transactions• accès READ COMMITTED
modèle par défaut
• accès SERIALIZABLE
Commande SQL
SET TRANSACTION ISOLATION LEVEL {SERIALIZABLE | READ COMMITTED}
29
Read committed
Modèle d'isolation standard implémenté par Oracle
• permet la concurrence des transactions
• seulement les données validées sont visibles aux autres transactions
Verrouillage des modifications
• Oracle gère l'accès en écriture en verrouillant les tuples qui seront modifiés
permet l'accès aux anciennes valeurs des tuples
empêche la modification des éléments des tuples verrouillés
30
Serializable
Les transactions sont effectuées les unes après les autres, de manière séquentielle
Résout le problème des lectures non reproductibles
Très contraignant pour le système
• empêche l'exécution concurrent des transactions
31
Niveaux de verrouillage avec Oracle
Verrouillage des tuples• implémentation standard d'Oracle• chaque tuple peut être verrouillé individuellement (et
pour des transactions différentes)• l'accès par d'autres transactions se fait en lecture
seule (avec les valeurs précédentes à la transaction)
Mécanisme de verrouillage• un verrou DML (data manipulation language)
empêche d'autres transactions d'écrire sur le tuple
• un verrou DDL (data dictionary language) sur la table empêche la modification de la structure de la table
• ces verrous ne sont relâchés qu'après un commit ou rollback
32
Niveaux de verrouillage avec Oracle
Verrouillage des tables• seule la transaction qui a posé le verrou peut modifier
la table• l'accès par d'autres transactions se fait en lecture
seule
Relâche des verrous• il est important de relâcher les verrous lorsqu'on ne les
utilise plus évite des interblocages permet aux autres transactions d'avancer
• effectuer des COMMIT ou ROLLBACK dès que possible
33
Les types de verrouillage
Oracle gère les types de verrouillage suivants :
• row share (RS)
• row exclusive (RX)
• share (S)
• share row exclusive (SRX)
• exclusive (X)
Certains de ces types s'appliquent automatiquement lors des requêtes SQL
34
Les types de verrouillage - aucun
Aucun verrou
• lors d'une requête SELECT simple le système ne pose aucun verrou
on suppose une opération de lecture seule
• tout contrôle dépend du mode d'accès permis aux données visualisées
35
Les types de verrouillage - RS
Row Share (RS)
• le type le moins restrictif
• une transaction pose le verrou sur une tuple
• opérations qui posent un RS
SELECT … FROM table … FOR UPDATE OF … ;
LOCK TABLE table IN ROW SHARE MODE [NOWAIT];
• les autres transactions ont le droit de consulter les données de cette tuple de verrouiller d'autres tuples dans la même table de poser des verrous de type RS, RX, S et SRX
• ce verrou sert à empêcher la pose d'un verrou X avant que votre mise à jour soit effectuée
36
Les types de verrouillage - RX
Row Exclusive (RX)
• opérations qui posent un RX
INSERT INTO table ... ;
UPDATE table ... ;
DELETE FROM table ... ;
LOCK TABLE table IN ROW EXCLUSIVE MODE [NOWAIT];
• les autres transactions ont le droit de consulter les données de cette tuple de verrouiller d'autres tuples dans la même table de poser des verrous de type RX, S et SRX
• ce verrou sert à empêcher une requête de verrouiller la table entière (en lecture ou écriture)
37
Les types de verrouillage - S
Share (S)
• opérations qui posent un S
LOCK TABLE table IN SHARE MODE [NOWAIT];
• les autres transactions ont le droit
de consulter les données de cette table
de verrouiller em mode share certaines tuples
de poser des verrous de type S
• aucun verrou plus restrictif (X, RX, SRX) n'est permis
• la mise à jour sur cette table dépend du fait que aucune autre transaction a des verrous sur la table
38
Les types de verrouillage - SRX
Share Row Exclusive (SRX)
• opérations qui posent un SRX
LOCK TABLE table IN SHARE ROW EXCLUSIVE MODE [NOWAIT];
• un seul verrou SRX est permis dans une table
• donne aux autres transactions seulement le droit de lecture (sauf des verrous SR avec SELECT...FOR UPDATE)
• la mise à jour sur cette table ne peut être faite que pour la transaction qui détient le verrou
39
Les types de verrouillage - X
Exclusive (X)
• opérations qui posent un X
LOCK TABLE table IN EXCLUSIVE MODE [NOWAIT];
• un seul verrou X est permis dans une table
• donne aux autres transactions seulement le droit de lecture
• garantit les propriétés de lecture cohérente
40
Exercices
TD Verrous
TP Verrouillage et concurrence d'accès sur Oracle