Niveaux d'isolement des transactions

2.1 Lecture non validée

Le "niveau d'isolement des transactions" fait référence au degré de protection fourni par les mécanismes internes du SGBD (c'est-à-dire ne nécessitant pas de programmation spéciale) contre tout ou partie des types d'incohérences de données ci-dessus qui se produisent lors de l'exécution parallèle de transactions. La norme SQL-92 définit une échelle de quatre niveaux d'isolement :

• Lire non validé
• Lecture validée
• Lecture répétable
• Sérialisable

Le premier d'entre eux est le plus faible, le dernier est le plus fort, chaque suivant comprend tous les précédents.

Le niveau d'isolement le plus bas (le premier). Si plusieurs transactions parallèles tentent de modifier la même ligne de table, la dernière ligne aura une valeur déterminée par l'ensemble des transactions terminées avec succès. Dans ce cas, il est possible de lire non seulement des données logiquement incohérentes, mais également des données dont les modifications n'ont pas encore été enregistrées.

Une manière typique d'implémenter ce niveau d'isolement consiste à verrouiller les données pendant l'exécution de la commande de modification, ce qui garantit que les commandes de modification sur les mêmes lignes exécutées en parallèle sont réellement exécutées de manière séquentielle et qu'aucune des modifications n'est perdue. Les transactions en lecture seule ne se bloquent jamais sous ce niveau d'isolement.

2.2 Lecture validée

La plupart des SGBD industriels, notamment Microsoft SQL Server, PostgreSQL et Oracle, utilisent ce niveau par défaut. À ce niveau, une protection contre les brouillons, la lecture «sale» est fournie, cependant, lors de l'opération d'une transaction, une autre peut être complétée avec succès et les modifications apportées par celle-ci sont corrigées. Par conséquent, la première transaction fonctionnera avec un ensemble de données différent.

La mise en œuvre d'une lecture complète peut être basée sur l'une des deux approches suivantes : le blocage ou le versionnage.

Blocage des données lisibles et modifiables.

Cela consiste dans le fait que la transaction d'écriture bloque les données modifiables pour lire les transactions fonctionnant au niveau de lecture validée ou supérieur jusqu'à ce qu'elles se terminent, empêchant ainsi la lecture "sale", et les données verrouillées par la transaction de lecture sont libérées immédiatement après la fin de l'opération. SELECT(ainsi, une situation de "lecture non répétable" peut se produire à un niveau d'isolement donné).

Enregistrement de plusieurs versions de lignes qui changent en parallèle.

Chaque fois qu'une ligne est modifiée, le SGBD crée une nouvelle version de cette ligne, avec laquelle la transaction qui a modifié les données continue de fonctionner, tandis que toute autre transaction de "lecture" renvoie la dernière version validée. L'avantage de cette approche est qu'elle est plus rapide car elle évite le blocage. Cependant, il nécessite, par rapport au premier, une consommation de RAM nettement supérieure, qui est consacrée au stockage des versions de ligne.

De plus, lorsque plusieurs transactions modifient des données en parallèle, cela peut créer une situation où plusieurs transactions simultanées apportent des modifications incohérentes aux mêmes données (puisqu'il n'y a pas de verrous, rien n'empêchera que cela se produise). Ensuite, la transaction qui s'engage en premier enregistrera ses modifications dans la base de données principale, et les transactions parallèles restantes seront impossibles à engager (car cela entraînera la perte de la mise à jour de la première transaction). La seule chose que le SGBD peut faire dans une telle situation est d'annuler le reste des transactions et d'émettre un message d'erreur "L'enregistrement a déjà été modifié".

Une méthode de mise en œuvre spécifique est choisie par les développeurs de SGBD et, dans certains cas, elle peut être personnalisée. Ainsi, par défaut, MS SQL utilise des verrous, mais (dans la version 2005 et supérieure) lors de la définition du READ_COMMITTED_SNAPSHOTparamètre de base de données, il passe à la stratégie de version, Oracle ne fonctionne initialement que selon le schéma versionné. Dans Informix, vous pouvez empêcher les conflits entre les transactions de lecture et d'écriture en définissant une option de configuration USELASTCOMMITTED(à partir de la version 11.1) qui fait que la transaction de lecture reçoit les dernières données validées.

2.3 Lecture répétable

Niveau auquel une transaction de lecture "ne voit pas" les modifications apportées aux données qu'elle a précédemment lues. Dans le même temps, aucune autre transaction ne peut modifier les données lues par la transaction en cours jusqu'à ce qu'elle se termine.

Les verrous en mode partagé sont appliqués à toutes les données lues par n'importe quelle instruction dans une transaction et sont maintenus jusqu'à ce que la transaction se termine. Cela empêche les autres transactions de modifier les lignes qui ont été lues par la transaction en attente. Cependant, d'autres transactions peuvent insérer des retours à la ligne correspondant aux conditions de recherche des instructions contenues dans la transaction en cours. Lorsque l'instruction est redémarrée par la transaction en cours, de nouvelles lignes sont extraites, ce qui entraîne une lecture fantôme.

Étant donné que les verrous partagés sont conservés jusqu'à la fin de la transaction, plutôt que d'être libérés à la fin de chaque instruction, le degré de concurrence est inférieur au niveau d'isolement READ COMMITTED. Par conséquent, il n'est généralement pas recommandé d'utiliser inutilement ce niveau de transaction et les niveaux supérieurs.

2.4 Sérialisable

Le plus haut niveau d'isolement; les transactions sont complètement isolées les unes des autres, chacune est exécutée comme s'il n'y avait pas de transactions parallèles. Ce n'est qu'à ce niveau que les transactions concurrentes ne sont pas soumises à l'effet " lecture fantôme ".

2.5 Prise en charge de l'isolation des transactions dans un SGBD réel

Les SGBD transactionnels ne prennent pas toujours en charge les quatre niveaux et peuvent également en introduire d'autres. Il existe également diverses nuances dans l'isolation.

Ainsi, en principe, Oracle ne prend pas en charge le niveau zéro, car sa mise en œuvre des transactions exclut les « lectures modifiées » et ne permet formellement pas de définir le niveau de lecture répétable, c'est-à-dire qu'il ne prend en charge que ( par défaut) Read committedet Serializable. En même temps, au niveau des commandes individuelles, cela garantit en fait la répétabilité de la lecture (si une commande SELECTdans la première transaction sélectionne un ensemble de lignes de la base de données, et qu'à ce moment une deuxième transaction parallèle modifie certaines de ces lignes, alors le l'ensemble de résultats reçu par la première transaction contiendra des lignes inchangées, comme s'il n'y avait pas de seconde transaction). Oracle prend également en charge les transactions dites READ-ONLY, qui correspondent à Serializable, mais ne peuvent pas modifier les données elles-mêmes.

Et Microsoft SQL Server prend en charge les quatre niveaux d'isolation de transaction standard, ainsi que le niveau SNAPSHOT, auquel la transaction voit l'état des données qui a été validé avant son lancement, ainsi que les modifications apportées par elle-même, c'est-à-dire qu'elle se comporte comme s'il a reçu au démarrage, un instantané des données de la base de données et fonctionne avec. La différence avec Serialized est qu'aucun verrou n'est utilisé, mais par conséquent, la validation des modifications peut ne pas être possible si une transaction concurrente a déjà modifié les mêmes données ; dans ce cas, la seconde transaction, lors de sa tentative d'exécution, COMMITgénère un message d'erreur et est annulée.