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 :
L’sale lecture de lectures incorrectesse 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 restaure la modification, la transaction 2 aura des données de lecture considérées comme n’ayant jamais existé.
Une lecture non répécable lit 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 erronées | Lectures non répécables | 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 implémenter les 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. De sorte qu’elles n’affectent pas les autres transactions, les transactions exécutées au niveau lecture non validée sont généralement en lecture seule. |
| Lecture validée | La transaction attend que les lignes verrouillées par d’autres transactions soient déverrouillées ; cela empêche la lecture des données « sale ». 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 restauré. |
| Lecture renouvelable | La transaction attend que les lignes verrouillées par d’autres transactions soient déverrouillées ; cela empêche la lecture des données « sale ». 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', la transaction écrit verrouille les lignes lorsqu’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 restaurée. |
| Sérialisable | La transaction attend que les lignes verrouillées par d’autres transactions soient déverrouillées ; cela empêche la lecture des données « sale ». 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 aucune nouvelle ligne à y insérer. 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 un é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 la plage, la transaction actuelle évite les fantômes. La transaction libère son verrou lorsqu’elle est validée ou restauré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 relevés UPDATE , dont le premier augmente le salaire de tous les employés de 10 pour cent et le deuxième, qui définit le salaire de tous les employés sur un montant maximal. Cela réussit en tant que transaction unique uniquement, car la deuxième instruction UPDATE peut voir les résultats du premier.