Institut Quantum Académie (IQAC) Administration des Bases de Données

MODULE 3

TRANSACTIONS ET CONCURRENCE

Administration des Bases de Données

Institut Quantum Académie (IQAC)

Module 3 : Transactions et Concurrence Page 1

Institut Quantum Académie (IQAC) Administration des Bases de Données

Introduction
Les transactions constituent le coeur de tout système de gestion de bases de données. Elles
garantissent l'intégrité des données même en cas de pannes ou d'accès concurrents multiples. Ce
module explore les mécanismes fondamentaux qui permettent aux SGBD de maintenir la cohérence
des données.

1. Concept de Transaction

1.1 Définition
Une transaction est une unité logique de travail composée d'une ou plusieurs opérations qui doivent
être exécutées de manière atomique. Elle représente une séquence d'actions qui transforme la base
de données d'un état cohérent à un autre état cohérent.

1.2 Propriétés ACID

Les transactions doivent respecter quatre propriétés fondamentales :

Atomicité : Une transaction est indivisible. Soit toutes ses opérations sont exécutées avec
succès, soit aucune ne l'est. En cas d'échec partiel, le système annule toutes les modifications
effectuées.
Cohérence : Une transaction fait passer la base de données d'un état cohérent à un autre état
cohérent. Toutes les contraintes d'intégrité doivent être respectées à la fin de la transaction.
Isolation : Les transactions concurrentes s'exécutent comme si elles étaient seules. Les
modifications d'une transaction en cours ne sont pas visibles par les autres transactions tant
qu'elle n'est pas validée.
Durabilité : Une fois validée, les modifications d'une transaction sont permanentes et survivent
aux pannes système.

1.3 Cycle de vie d'une transaction

Une transaction passe par plusieurs états :

• Active : La transaction est en cours d'exécution

• Partiellement validée : Toutes les opérations ont été exécutées, en attente de validation
• Validée (Committed) : La transaction est terminée avec succès
• Échouée : Une erreur s'est produite
• Annulée (Aborted) : Les modifications ont été défaites

1.4 Commandes de contrôle

BEGIN TRANSACTION; -- Démarre une transaction

Module 3 : Transactions et Concurrence Page 2

Institut Quantum Académie (IQAC) Administration des Bases de Données

COMMIT; -- Valide la transaction

ROLLBACK; -- Annule la transaction

SAVEPOINT nom_point; -- Crée un point de sauvegarde

ROLLBACK TO nom_point; -- Retour au point de sauvegarde

2. Problèmes de Concurrence
Lorsque plusieurs transactions s'exécutent simultanément, plusieurs anomalies peuvent survenir.

2.1 Lecture sale (Dirty Read)

Une transaction lit des données modifiées par une autre transaction non encore validée. Si cette
dernière est annulée, la première aura lu des données qui n'ont jamais existé officiellement.
Exemple : T1 modifie le solde d'un compte de 1000 à 500. T2 lit ce solde à 500. T1 est annulée. T2 a lu une
valeur incorrecte.

2.2 Lecture non répétable (Non-Repeatable Read)

Une transaction relit des données qu'elle a déjà lues et constate qu'elles ont été modifiées par une
autre transaction validée entre-temps.
Exemple : T1 lit le solde à 1000. T2 modifie le solde à 800 et valide. T1 relit le solde et trouve 800.

2.3 Lecture fantôme (Phantom Read)

Une transaction réexécute une requête et obtient un ensemble de lignes différent car une autre
transaction a inséré ou supprimé des lignes correspondant aux critères de recherche.
Exemple : T1 compte les clients d'une ville et trouve 100. T2 insère un nouveau client dans cette ville et
valide. T1 recompte et trouve 101.

2.4 Perte de mise à jour (Lost Update)

Deux transactions lisent la même donnée puis la modifient. La deuxième écriture écrase la première
sans tenir compte de sa modification.
Exemple : T1 et T2 lisent un solde à 1000. T1 ajoute 200, écrit 1200. T2 retire 100, écrit 900. La modification
de T1 est perdue.

Module 3 : Transactions et Concurrence Page 3

Institut Quantum Académie (IQAC) Administration des Bases de Données

3. Niveaux d'Isolation
SQL définit quatre niveaux d'isolation offrant différents compromis entre cohérence et performance.

3.1 Read Uncommitted

Niveau le plus faible. Autorise les lectures sales. Utilisé uniquement pour des lectures statistiques où
la précision absolue n'est pas requise.

3.2 Read Committed

Empêche les lectures sales. Une transaction ne voit que les données validées. C'est le niveau par
défaut de nombreux SGBD comme PostgreSQL et Oracle.

3.3 Repeatable Read

Empêche les lectures sales et non répétables. Les données lues une fois restent stables pendant
toute la transaction. Niveau par défaut de MySQL/InnoDB.

3.4 Serializable
Niveau le plus strict. Empêche tous les problèmes de concurrence, y compris les lectures fantômes.
Les transactions s'exécutent comme si elles étaient séquentielles.

Tableau récapitulatif :

Niveau Lecture sale Lecture non répétable Fantôme

Read Uncommitted Possible Possible Possible

Read Committed Impossible Possible Possible

Repeatable Read Impossible Impossible Possible

Serializable Impossible Impossible Impossible

3.5 Syntaxe

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

Module 3 : Transactions et Concurrence Page 4

Institut Quantum Académie (IQAC) Administration des Bases de Données

4. Mécanismes de Verrouillage
Le verrouillage est la technique principale pour gérer la concurrence.

4.1 Types de verrous

Verrou partagé (Shared Lock / S) : Permet la lecture. Plusieurs transactions peuvent détenir un
verrou partagé sur la même ressource simultanément.
Verrou exclusif (Exclusive Lock / X) : Permet la lecture et l'écriture. Une seule transaction peut
détenir un verrou exclusif. Incompatible avec tout autre verrou.

Matrice de compatibilité :

S X

S ✓ ✗

X ✗ ✗

4.2 Granularité des verrous

Les verrous peuvent s'appliquer à différents niveaux :

• Base de données : Verrouille toute la base

• Table : Verrouille une table entière
• Page : Verrouille un bloc de données
• Ligne : Verrouille une ligne spécifique
• Attribut : Verrouille une colonne d'une ligne
Une granularité fine offre plus de concurrence mais engendre une surcharge de gestion plus
importante.

4.3 Protocole de verrouillage à deux phases (2PL)

Ce protocole garantit la sérialisabilité des transactions en imposant deux règles :

Phase d'expansion : Une transaction peut acquérir des verrous mais ne peut en libérer aucun.
Phase de contraction : Une transaction peut libérer des verrous mais ne peut plus en acquérir.
Le point de verrouillage maximal marque la transition entre les deux phases.

Variantes :

• 2PL strict : Tous les verrous exclusifs sont libérés uniquement à la fin de la transaction
• 2PL rigoureux : Tous les verrous sont libérés uniquement à la fin de la transaction

4.4 Verrouillage intentionnel

Module 3 : Transactions et Concurrence Page 5

Institut Quantum Académie (IQAC) Administration des Bases de Données

Pour les systèmes avec verrouillage hiérarchique, des verrous d'intention indiquent qu'un verrou plus
fin existe à un niveau inférieur :

• IS (Intention Shared) : Indique un verrou partagé à un niveau inférieur

• IX (Intention Exclusive) : Indique un verrou exclusif à un niveau inférieur
• SIX : Verrou partagé sur la ressource avec intention exclusive sur des sous-ressources

Module 3 : Transactions et Concurrence Page 6

Institut Quantum Académie (IQAC) Administration des Bases de Données

5. Interblocage (Deadlock)

5.1 Définition
Un interblocage survient quand deux ou plusieurs transactions s'attendent mutuellement pour libérer
des ressources, créant un cycle d'attente infini.
Exemple classique : T1 détient un verrou sur A, attend un verrou sur B. T2 détient un verrou sur B, attend
un verrou sur A.

5.2 Conditions nécessaires

Quatre conditions doivent être réunies simultanément :

1. Exclusion mutuelle : Les ressources ne peuvent être partagées

2. Détention et attente : Une transaction détient des ressources tout en attendant d'autres
3. Non-préemption : Les ressources ne peuvent être retirées de force
4. Attente circulaire : Un cycle existe dans le graphe d'attente

5.3 Prévention
Approche par estampillage : Chaque transaction reçoit un timestamp. Deux stratégies principales :

• Wait-Die : Une transaction plus ancienne peut attendre une plus récente, sinon elle meurt
(redémarre)
• Wound-Wait : Une transaction plus ancienne blesse (force le redémarrage) une plus récente,
sinon elle attend
Approche par délai : Si une transaction attend trop longtemps, elle est automatiquement annulée.

5.4 Détection
Le système construit périodiquement un graphe d'attente. Un cycle dans ce graphe indique un
interblocage. Une transaction du cycle est alors choisie comme victime et annulée.

Critères de sélection de la victime :

• Transaction ayant le moins de travail effectué

• Transaction la plus récente
• Transaction détenant le moins de ressources

5.5 Résolution
Une fois l'interblocage détecté, la transaction victime est annulée (rollback) et ses ressources libérées.
Elle peut ensuite être redémarrée.

6. Techniques de Récupération

Module 3 : Transactions et Concurrence Page 7

Institut Quantum Académie (IQAC) Administration des Bases de Données

6.1 Journalisation (Logging)

Le journal de transactions enregistre toutes les modifications avant qu'elles ne soient appliquées à la
base de données.

Types d'entrées :

• BEGIN : Début de transaction

• WRITE(T, X, ancienne_valeur, nouvelle_valeur) : Modification
• COMMIT : Validation
• ABORT : Annulation
Protocole WAL (Write-Ahead Logging) : Avant d'écrire une modification dans la base, l'entrée
correspondante doit être écrite dans le journal.

6.2 Points de contrôle (Checkpoints)

Un checkpoint force l'écriture de toutes les pages modifiées en mémoire vers le disque et enregistre
l'état des transactions actives. Cela limite la quantité de journal à parcourir lors de la récupération.

6.3 Algorithme ARIES

ARIES (Algorithm for Recovery and Isolation Exploiting Semantics) est l'algorithme de récupération le
plus utilisé. Il procède en trois phases :

Phase d'analyse : Parcourt le journal depuis le dernier checkpoint pour identifier les transactions
actives au moment de la panne et les pages modifiées.
Phase REDO : Rejoue toutes les modifications depuis le dernier checkpoint pour restaurer l'état
de la base au moment de la panne.
Phase UNDO : Annule les modifications des transactions non validées en parcourant le journal à
l'envers.

Module 3 : Transactions et Concurrence Page 8

Institut Quantum Académie (IQAC) Administration des Bases de Données

7. Contrôle de Concurrence Optimiste

7.1 Principe
Contrairement au verrouillage pessimiste, l'approche optimiste suppose que les conflits sont rares. Les
transactions s'exécutent sans verrous, et les conflits sont détectés uniquement au moment de la
validation.

7.2 Phases
Phase de lecture : La transaction lit les données et effectue ses calculs sur des copies locales.
Phase de validation : Le système vérifie qu'aucun conflit n'existe avec d'autres transactions.
Phase d'écriture : Si la validation réussit, les modifications sont appliquées. Sinon, la transaction
est annulée et redémarrée.

7.3 Avantages et inconvénients

L'approche optimiste convient aux environnements avec peu de conflits et beaucoup de lectures. Elle
évite la surcharge de gestion des verrous mais peut entraîner de nombreux redémarrages si les
conflits sont fréquents.

8. Contrôle par Estampillage

8.1 Principe
Chaque transaction reçoit un timestamp unique à son démarrage. Les opérations sont ordonnées
selon ces timestamps pour garantir la sérialisabilité.

8.2 Règles
Chaque donnée X possède deux timestamps :

• RT(X) : Timestamp de la dernière transaction ayant lu X

• WT(X) : Timestamp de la dernière transaction ayant écrit X
Règle de lecture : Si TS(T) < WT(X), la transaction T tente de lire une valeur écrite par une
transaction future. T doit être annulée.

Règle d'écriture : Si TS(T) < RT(X) ou TS(T) < WT(X), la transaction T tente d'écrire une valeur qui a
déjà été lue ou écrite par une transaction future. T doit être annulée.

9. MVCC (Multi-Version Concurrency Control)

9.1 Principe

Module 3 : Transactions et Concurrence Page 9

Institut Quantum Académie (IQAC) Administration des Bases de Données

Le système maintient plusieurs versions de chaque donnée. Chaque transaction voit un instantané
cohérent de la base au moment de son démarrage, sans bloquer les autres transactions.

9.2 Fonctionnement
Lors d'une écriture, une nouvelle version de la donnée est créée sans supprimer l'ancienne. Les
lecteurs accèdent à la version appropriée selon leur timestamp, sans nécessiter de verrous.

9.3 Implémentations
PostgreSQL utilise MVCC avec un système de versions par ligne. Chaque ligne possède des
identifiants de transaction indiquant quand elle a été créée et supprimée. Oracle utilise des segments
de rollback pour reconstruire les anciennes versions.

9.4 Nettoyage
Les anciennes versions devenues inutiles doivent être supprimées. PostgreSQL utilise VACUUM,
Oracle recycle automatiquement les segments de rollback.

10. Transactions Distribuées

10.1 Contexte
Dans un système distribué, une transaction peut impliquer plusieurs noeuds. La validation doit être
coordonnée pour garantir l'atomicité globale.

10.2 Protocole 2PC (Two-Phase Commit)

Phase de préparation : Le coordinateur demande à chaque participant s'il peut valider. Chaque
participant répond "Prêt" ou "Abandon".
Phase de décision : Si tous les participants sont prêts, le coordinateur envoie "Commit" à tous.
Sinon, il envoie "Abort".
Problème : Si le coordinateur tombe en panne après la phase de préparation, les participants restent
bloqués.

10.3 Protocole 3PC (Three-Phase Commit)

Ajoute une phase intermédiaire "Pre-commit" pour éviter le blocage. Si le coordinateur tombe en
panne, les participants peuvent décider eux-mêmes en fonction de l'état des autres participants.

Module 3 : Transactions et Concurrence Page 10

Institut Quantum Académie (IQAC) Administration des Bases de Données

Travaux Pratiques

Exercice 1 : Identification des anomalies

Considérez l'exécution suivante de deux transactions T1 et T2 sur une variable X initialisée à 100 :

T1: READ(X)

T2: READ(X)

T1: X = X + 50

T2: X = X - 30

T1: WRITE(X)

T2: WRITE(X)

T1: COMMIT

T2: COMMIT

Identifiez l'anomalie présente et proposez une solution.

Exercice 2 : Détection d'interblocage

Trois transactions T1, T2, T3 accèdent aux ressources A, B, C :

• T1 détient A, demande B
• T2 détient B, demande C
• T3 détient C, demande A
Dessinez le graphe d'attente et identifiez l'interblocage.

Exercice 3 : Protocole 2PL

Pour la séquence d'opérations suivante, appliquez le protocole 2PL strict :

T1: READ(A), WRITE(A), READ(B)

T2: READ(B), WRITE(B)

Indiquez les verrous acquis et libérés à chaque étape.

Exercice 4 : Niveaux d'isolation

Un système bancaire effectue un virement de 200€ du compte A vers le compte B. Quel niveau
d'isolation minimum recommanderiez-vous ? Justifiez votre choix.

Module 3 : Transactions et Concurrence Page 11

Institut Quantum Académie (IQAC) Administration des Bases de Données

Résumé
Les transactions garantissent l'intégrité des données via les propriétés ACID. La gestion de la
concurrence repose sur différentes techniques : verrouillage pessimiste avec le protocole 2PL,
approche optimiste avec validation différée, contrôle par estampillage, ou MVCC. Chaque approche
présente des compromis entre niveau d'isolation, performance et complexité.

La détection et la résolution des interblocages sont essentielles pour éviter les blocages système. Les
mécanismes de journalisation et de récupération assurent la durabilité des transactions même en cas
de panne.

Module 3 : Transactions et Concurrence Page 12