22/02/2021

PLAY
TRANSACTIONS & ISOLATION

Transaction ‘debut ….fin’

PLAY

1
 22/02/2021

Propriétés ACID et systèmes commerciaux

• Garantir les propriétés ACID des transactions pénalise

les performances. Les systèmes commerciaux
relâchent souvent la propriété d’isolation.

• Conséquences :
PLAY
Lecture sale
Lecture non reproductible
Lecture fantôme

Dirty read
Une transaction lit une donnée écrite par une transaction qui n’a
pas encore validé.

PLAY

2
 22/02/2021

Lecture non répétitive (fuzzy)

Une transaction lit deux fois la même donnée et obtient
des valeurs différentes.

PLAY

Lecture fântome
Deux évaluations de la même requête donnent des résultats
différents, car une autre transaction a inséré de nouveaux
nuplets entretemps

PLAY

4 enregistrements
inconhérentes

3
 22/02/2021

Degrés d’isolation SQL/restriction

PLAY ?

With read only

SET TRANSACTION

✓Spécifie le comportement de la transaction :

✓Est facultative.
✓Si elle est utilisée:
✓elle doit être la première instruction de la transaction,
✓et n’affecte que la transaction courante.

PLAY

SET TRANSACTION { { READ { ONLY | WRITE } | ISOLATION

LEVEL { SERIALIZABLE | READ COMMITTED } | USE
ROLLBACK SEGMENT rollback_segment } [ NAME string ] |
NAME string } ;

4
 22/02/2021

Degrés d’isolation ‘ Oracle’

Pour une transaction :

• SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

• SET TRANSACTION ISOLATION LEVEL READ COMMITTED

PLAY
Pour toutes les transactions à venir (dans une session)

• ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE;

• ALTER SESSION SET ISOLATION_LEVEL = READ COMMITTED;

ISOLATION LEVEL ‘READ COMMITTED’

• Option par défaut

• Les verrous en lecture sont relâchés dès la fin de la consultation de l’objet,

sans attendre la fin de la transaction

• Évite les lectures sales

PLAY
• Si la transaction contient une instruction qui nécessite un verrou de tuple tenu
par une autre transaction, il faut attendre que ce verrou soit libéré pour pouvoir
continuer.

• Utilisation
Peu de transactions concurrentes

5
 22/02/2021

ISOLATION LEVEL SERIALIZABLE

• L’exécution est équivalente à l’exécution séquentielle

• Empêche de modifier une ressource mise à jour par une transaction

non encore validée.

• Pas de lecture sale, pas de lecture non reproductible, pas de lecture

Fantôme pénalisant pour les performances

PLAY
•Utilisation :
– grandes BD avec nombreuses transactions courtes et mises à jour de
quelques n uplets seulement.
– Peu de transactions concurrentes (modifiant les même données)
– Lorsque les transactions longues sont essentiellement en lecture

Contrôle de cohérence multiversion

Permet d’éliminer des conflits de données, de réduire les verrous

mortels, et les conflits de verrous.

Ex: Mise à jour concurrente de la relation Authors(au_id, phone, ...)

Session 1 :

UPDATE authors
SET phone = ’01 23 45 67 89’ WHERE au_id = ‘123’

Session 2 : PLAY
SELECT * FROM authors
Pour lire le nuplet modifié par la session 1, la session 2 doit
attendre la fin de la transaction de la session 1.

6
 22/02/2021

Temporaire ‘image avant’

Contrôle de cohérence multiversion
Principe : maintenir les données de l’état précédent (version) jusqu’à la validation.
Les requêtes lisent l’ancienne version, et ne sont pas obligées d’attendre la fin
de la transaction qui fait les mises à jour.
Données de Authors (après le commit de la session 1):
Au_id
Phone
123
01 23 45 67 89...
456
99 88 77 66 55
...
Données temporaires (pendant le déroulement de la session 1) :
PLAY
Au_id
Phone
123
98 76 54 32 10
456
99 88 77 66 55
...
...
...
...

Verrouillage en Oracle

• Oracle utilise 2 modes de verrouillage :

• Verrous exclusifs (Exclusive locks) : pour modifier des données.

• Verrous partagés (Shared locks) : plusieurs transactions peuvent

partager des données, sans qu’aucune ne puisse les modifier.

PLAY

Les verrous sont relâchés :COMMIT

ROLLBACK.

7
 22/02/2021

Verrous mortels

PLAY

Wait_die/wound_wait (res dif !)

Verrous de tuple

Une transaction acquiert un verrou exclusif pour chaque tuple modifié par
INSERT, UPDATE, DELETE, SELECT ...FOR UPDATE

Les verrous de tuple, en combinaison avec la cohérence multiversion,

– Permettent de lire une donnée sans attendre, même si une autre transaction écrit
une donnée du même tuple.

PLAY
– Evitent les blocages des écritures par les lectures des mêmes données, sauf en cas
de SELECT ... FOR UPDATE

8
 22/02/2021

Verrous de table
Une transaction acquiert un verrou de table pour chaque relation
modifiée par une instruction INSERT, UPDATE, DELETE
SELECT .. FOR UPDATE et LOCK TABLE.

Permet de réserver les accès du DML pour une transaction donnée et empêche
les opérations du DDL.

Plusieurs modes :

PLAY