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.
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.
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.
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.
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
.