Niveaux d’isolation des transactions (ODBC)

Les niveaux d’isolation des transactions sont une mesure de la mesure dans laquelle l’isolation des transactions réussit. En particulier, les niveaux d’isolation des transactions sont définis par la présence ou l’absence des phénomènes suivants :

• Lectures incorrectes Une lecture incorrecte se produit lorsqu’une transaction lit les données qui n’ont pas encore été validées. Par exemple, supposons que la transaction 1 met à jour une ligne. La transaction 2 lit la ligne mise à jour avant que la transaction 1 valide la mise à jour. Si la transaction 1 annule la modification, la transaction 2 aura lu des données considérées comme n’ayant jamais existé.

• Lectures non répécables Une lecture non répécable se produit lorsqu’une transaction lit la même ligne deux fois, mais obtient des données différentes à chaque fois. Par exemple, supposons que la transaction 1 lit une ligne. La transaction 2 met à jour ou supprime cette ligne et valide la mise à jour ou la suppression. Si la transaction 1 réécrit la ligne, elle récupère différentes valeurs de ligne ou découvre que la ligne a été supprimée.

• Fantômes Un fantôme est une ligne qui correspond aux critères de recherche, mais qui n’est pas initialement vue. Par exemple, supposons que la transaction 1 lit un ensemble de lignes qui répondent à certains critères de recherche. La transaction 2 génère une nouvelle ligne (via une mise à jour ou une insertion) qui correspond aux critères de recherche de la transaction 1. Si la transaction 1 réexécute l’instruction qui lit les lignes, elle obtient un ensemble différent de lignes.

Les quatre niveaux d’isolation des transactions (tels que définis par SQL-92) sont définis en termes de ces phénomènes. Dans le tableau suivant, un « X » marque chaque phénomène qui peut se produire.

Niveau d’isolation des transactions	Lectures incorrectes	Lectures non répétables	Fantômes
Lecture non validée	X	X	X
Lecture validée	--	X	X
Lecture renouvelable	--	--	X
Sérialisable	--	--	--

Le tableau suivant décrit les méthodes simples qu’un SGBD peut utiliser pour implémenter des niveaux d’isolation des transactions.

Important

La plupart des SGBD utilisent des schémas plus complexes que ceux-ci pour augmenter la concurrence. Ces exemples sont fournis uniquement à des fins d’illustration. En particulier, ODBC ne prescrit pas comment les SGBD particuliers isolent les transactions les unes des autres.

Isolation des transactions	Implémentation possible
Lecture non validée	Les transactions ne sont pas isolées les unes des autres. Si le SGBD prend en charge d’autres niveaux d’isolation des transactions, il ignore le mécanisme qu’il utilise pour implémenter ces niveaux. Pour qu'elles n'affectent pas les autres transactions, les transactions au niveau Read Uncommitted sont souvent en lecture seule.
Lecture validée	La transaction attend que les lignes verrouillées pour écriture par d’autres transactions soient déverrouillées ; cela empêche la lecture de données « non validées ». La transaction contient un verrou de lecture (s’il lit uniquement la ligne) ou un verrou d’écriture (s’il met à jour ou supprime la ligne) sur la ligne active pour empêcher d’autres transactions de mettre à jour ou de le supprimer. La transaction libère les verrous de lecture lorsqu’elle se déplace hors de la ligne actuelle. Il contient des verrous d’écriture jusqu’à ce qu’il soit validé ou annulé.
Lecture renouvelable	La transaction attend que les lignes verrouillées par d’autres transactions soient déverrouillées ; cela empêche la lecture de données « incorrectes ». La transaction contient des verrous de lecture sur toutes les lignes qu’elle retourne à l’application et écrit des verrous sur toutes les lignes qu’elle insère, met à jour ou supprime. Par exemple, si la transaction inclut l’instruction SQL SELECT * FROM Orders, la transaction verrouille les lignes à mesure que l’application les récupère. Si la transaction inclut l’instruction SQL DELETE FROM Orders WHERE Status = 'CLOSED', elle verrouille les lignes en écriture au fur et à mesure qu'elle les supprime. Étant donné que d’autres transactions ne peuvent pas mettre à jour ou supprimer ces lignes, la transaction actuelle évite les lectures non répélétables. La transaction libère ses verrous lorsqu'elle est validée ou annulée.
Sérialisable	La transaction attend que les lignes verrouillées en écriture par d'autres transactions soient déverrouillées ; cela empêche la lecture de données « sales ». La transaction contient un verrou de lecture (s’il lit uniquement les lignes) ou un verrou d’écriture (s’il peut mettre à jour ou supprimer des lignes) sur la plage de lignes qu’elle affecte. Par exemple, si la transaction inclut l’instruction SQL SELECT * FROM Orders, la plage est la table Orders entière ; la transaction verrouille la table et n’autorise pas l’insertion de nouvelles lignes. Si la transaction inclut l’instruction SQL DELETE FROM Orders WHERE Status = 'CLOSED', la plage est toutes les lignes avec l’état « CLOSED » ; la transaction verrouille toutes les lignes de la table Orders avec l’état « CLOSED » et n’autorise aucune ligne à insérer ou à mettre à jour de telle sorte que la ligne résultante ait l’état « CLOSED ». Étant donné que d’autres transactions ne peuvent pas mettre à jour ou supprimer les lignes de la plage, la transaction actuelle évite les lectures non répécables. Étant donné que d'autres transactions ne peuvent pas insérer de lignes dans l'intervalle, la transaction actuelle évite les fantômes. La transaction libère son verrou lorsqu’elle est validée ou annulée.

Il est important de noter que le niveau d’isolation des transactions n’affecte pas la capacité d’une transaction à voir ses propres modifications ; les transactions peuvent toujours voir les modifications qu’elles apportent. Par exemple, une transaction peut se composer de deux instructions UPDATE, dont la première augmente le salaire de tous les employés de 10 pour cent et la deuxième fixe le salaire des employés dont le salaire dépasse un montant maximal à ce montant. Cela réussit en tant que transaction unique uniquement, car la deuxième instruction UPDATE peut voir les résultats du premier.