2. Isolation des transactions

Les transactions ont été créées entre autres pour gérer les modifications concurrentes d'une base de données : comment les choses doivent-elles se passer lorsque deux opérateurs tentent de modifier les mêmes données ?

2.1. ACIDité d'une transaction

Les propriétés d'une transaction ont été définies dans les années 70 par Jim Gray, qui les a rassemblées sous l'acronyme ACID : Atomicity, Consistency, Isolation, Durability.

2.1.1. Atomicité

L'atomicité désigne ce que nous avons décrit en introduction de ce chapitre. Toutes les opérations d'une transaction sont solidaires, si l'une échoue, alors toute la transaction doit échouer.

2.1.2. Cohérence

Cela signifie qu'une transaction doit mener la base de données d'un état cohérent à un autre état cohérent. Cohérent signifie que toutes les contraintes définies sur les données de la base doivent être vérifiées avant et après l'exécution de toute transaction.

2.1.3. Isolation

Une transaction isolée signifie que les modifications qu'elles appliquent à la base durant son fonctionnement ne doivent être vues que d'elle. Prenons l'exemple d'une transaction qui crée des données dans la table Marins. Tant que la transaction n'est pas terminée, tous les utilisateurs qui ne se trouvent pas dans cette transaction ne doivent pas voir les données créées.

2.1.4. Durabilité

La durabilité d'une transaction signifie qu'une fois une transaction terminée, et que le serveur a indiqué que les modifications ont bien été prises en compte, alors les données ne seront pas "oubliées" en cas de panne majeure (hardware notamment).

2.2. Définition de l'isolation

Définir le niveau d'isolation d'une transaction revient à relacher la contrainte d'isolation telle que définie par Jim Gray. Effectivement, cette isolation est le plus souvent obtenue en empêchant purement et simplement certaines lectures sur les tables en cours de modification, ce qui a un impact parfois inacceptable sur les performances. L'isolation d'une transaction est garantie par l'acquisition de verrous sur les données manipulées. Le niveau d'isolation dans lequel une transaction travaille indique en fait le type de verrou qu'elle est autorisée à poser sur les données. Quatre niveaux d'isolation sont définis, que nous allons examiner en détails.

2.2.1. Isolation serializable

Il s'agit du niveau le plus fort. Ce niveau garantit une indépendance parfaite entre les différentes transactions.

2.2.2. Isolation repeatable_read

Ce niveau permet de garantir que les lectures effectuées par un select ne seront pas modifiées, sauf si ce select contient une clause where permettant de sélectionner une plage de données. C'est le cas de la clause where ddnaissance < 1800 and ddnaissance > 1700. Dans le cas d'une transaction repeatable_read, effectuer deux fois une telle requête peut amener des données fantômes, créées dans une autre transaction. On appelle ces données des phantom read .

2.2.3. Isolation read_commited

Ce niveau d'isolation signifie qu'une donnée manipulée dans la transaction courante peut être modifiée par une autre transaction, et que cette modification peut être vue une fois que cette autre transaction a été validée. On appelle ces données lues des non-repeatable read .

2.2.4. Isolation read_uncommited

Ce niveau d'isolation est le plus lache de tous. Il signifie qu'une donnée manipulée dans la transaction courante peut être modifiée par une autre transaction, et que cette modification peut être vue sans que cette autre transaction ait été validée. C'est ce que l'on appelle un dirty read .
Introduction à SQL
Retour au blog Java le soir
Cours & Tutoriaux
Table des matières
Introduction
1. Un peu d'histoire
2. Organisation de la présentation
Un premier exemple
1. Un premier exemple
1.1. Construction d'une première table
1.2. Enregistrer quelques données
1.3. Extraire des données
2. Trier, classer, calculer
2.1. Classer des données
2.2. Trier des données
2.3. Effectuer des calculs
2.4. Mise à jour d'une valeur
3. Sélection sur plusieurs tables
3.1. Ajout du lieu de naissance
3.2. Clés primaires et clés étrangères
Organisation des données
1. Introduction
2. Bases de données, schémas et tables
2.1. Création d'une table
2.2. Création d'une colonne
2.3. Contraintes sur une table
2.4. Nommage des contraintes
2.5. Exemples de création de tables
2.6. Modification d'une table
2.7. Effacement d'une table
2.8. Remarques sur restrict et cascade
3. Types de données
3.1. Les types numériques
3.2. Les types caractère
3.3. Les types temporels
3.4. Les types binaires
3.5. Type auto-incrémental de MySQL
3.6. Type auto-généré de Derby
3.7. Séquences d'Oracle
Manipulation des données
1. Introduction
2. Extraire des données : select
2.1. Extraire des données d'une table unique
2.2. Clause where
2.3. Requêtes imbriquées
2.4. Fonctions d'agrégation, groupage
3. Supprimer des données : delete
3.1. Forme générale du delete
3.2. Effacement en cascade
3.3. Fonctionnement du delete
4. Ajouter des données : insert
4.1. Forme générale de l' insert
4.2. Copie d'une table dans une autre
5. Mettre à jour des données : update
5.1. Forme générale de l' update
5.2. Mise à jour avec une requête imbriquée
Interrogations sur plusieurs tables
1. Introduction
2. Formes normales
2.1. Première forme normale
2.2. Deuxième forme normale
2.3. Troisième forme normale
2.4. Formes normales d'ordres supérieurs
3. Relations entre éléments
3.1. Cardinalité d'une relation
3.2. Relation 1:1
3.3. Relation 1:p
3.4. Relation p:1
3.5. Relation n:p
4. Jointures
4.1. Jointure interne
4.2. Jointure externe
4.3. Auto-jointure
5. Unions
6. Vues
6.1. Création d'une vue
6.2. Exemples de vues
Transactions
1. Introduction
2. Isolation des transactions
2.1. ACIDité d'une transaction
2.2. Définition de l'isolation
3. Gestion d'une transaction
3.1. Mode auto-commit
3.2. Fixer le niveau d'isolation
3.3. Démarrer une transaction
3.4. Terminer une transaction
3.5. Remarques importantes
Index
1. Introduction
2. Manipulation d'index
2.1. Création automatique d'index
2.2. Création manuelle d'index