Problèmes de transactions simultanées

1.1 Introduction

Et maintenant, le plaisir commence - la théorie du fonctionnement des transactions. Comment faire en sorte que le système continue de fonctionner lorsque vous modifiez les mêmes données dans différents threads ? Ou voulez-vous exécuter une transaction dans une autre ? Nous allons commencer à chercher des réponses à ces questions en étudiant l'isolement des transactions...

Le niveau d'isolement de transaction est une valeur conditionnelle qui détermine dans quelle mesure, suite à l'exécution de transactions logiquement parallèles dans le SGBD, des données incohérentes sont autorisées. L'échelle des niveaux d'isolement des transactions contient un certain nombre de valeurs, classées de la plus faible à la plus élevée ; un niveau d'isolement plus élevé correspond à une meilleure cohérence des données, mais son utilisation peut réduire le nombre de transactions physiquement parallèles.

Inversement, un niveau d'isolement inférieur permet davantage de transactions parallèles, mais réduit la précision des données. Ainsi, en choisissant le niveau d'isolation des transactions utilisé, le développeur du système d'information offre, dans une certaine mesure, le choix entre la rapidité de travail et la garantie de cohérence des données reçues du système.

Problèmes d'accès simultané à l'aide de transactions

Lorsque des transactions sont exécutées en parallèle, les problèmes suivants sont possibles :

• mise à jour perdue - si un bloc de données est modifié simultanément par différentes transactions, toutes les modifications sont perdues, à l'exception de la dernière ;
• lecture "sale" (eng. Dirty read) - lecture des données ajoutées ou modifiées par une transaction, qui par la suite ne seront pas confirmées (annulées);
• lecture non répétable (eng. lecture non répétable) - lors de la relecture dans la même transaction, les données précédemment lues sont modifiées ;
• lectures fantômes - une transaction au cours de son exécution sélectionne plusieurs fois plusieurs lignes selon les mêmes critères. Une autre transaction entre ces extractions ajoute des lignes ou modifie des colonnes de certaines des lignes utilisées dans les critères d'extraction de la première transaction et se termine avec succès. En conséquence, il s'avérera que les mêmes sélections dans la première transaction donneront différents ensembles de lignes.

Considérez les situations dans lesquelles ces problèmes peuvent survenir.

1.2 Mise à jour perdue

Situation dans laquelle, lorsqu'un bloc de données est modifié simultanément par différentes transactions, l'une des modifications est perdue.

Supposons que deux transactions s'exécutent en même temps :

Dans les deux transactions, la valeur du champ f2 change ; à la fin, la valeur du champ doit être augmentée de 45. En fait, la séquence d'actions suivante peut se produire :

1. Les deux transactions lisent simultanément l'état actuel du champ. La concurrence physique exacte n'est pas requise ici, il suffit que la deuxième opération de lecture dans l'ordre soit terminée avant qu'une autre transaction n'écrive son résultat.
2. Les deux transactions calculent la nouvelle valeur de champ en ajoutant 20 et 25, respectivement, à la valeur précédemment lue.
3. Les transactions essaient d'écrire le résultat du calcul dans le champ f2. Puisqu'il est physiquement impossible d'effectuer deux écritures en même temps, en réalité l'une des opérations d'écriture sera effectuée plus tôt, l'autre plus tard. La deuxième opération d'écriture écrasera le résultat de la première.

En conséquence, la valeur du champ f2, à la fin des deux transactions, peut augmenter non pas de 45, mais de 20 ou 25, c'est-à-dire que l'une des transactions modifiant les données «disparaîtra».

1.3 Lecture "sale"

Lecture des données ajoutées ou modifiées par une transaction dont la validation échouera ultérieurement (rollback).

Supposons que nous ayons deux transactions ouvertes par différentes applications qui exécutent les instructions SQL suivantes :

Dans la transaction 1, la valeur du champ f2 est modifiée, puis dans la transaction 2, la valeur de ce champ est sélectionnée. Après cela, la transaction 1 est annulée. Par conséquent, la valeur reçue par la deuxième transaction sera différente de la valeur stockée dans la base de données.

1.4 Lecture non reproductible

La situation où, lors d'une relecture au sein d'une même transaction, des données précédemment lues se révèlent modifiées.

Supposons que nous ayons deux transactions ouvertes par différentes applications qui exécutent les instructions SQL suivantes :

Dans la transaction 2, la valeur du champ f2 est sélectionnée, puis dans la transaction 1, la valeur du champ f2 est modifiée. Si vous réessayez de sélectionner une valeur du champ f2 dans la transaction 2, un résultat différent sera obtenu. Cette situation est notamment inacceptable lorsque les données sont lues pour les modifier partiellement et les réécrire dans la base de données.

1.5 Lecture "fantômes"

La situation où, lors d'une lecture répétée au sein d'une même transaction, la même sélection donne différents ensembles de lignes.

Supposons qu'il existe deux transactions ouvertes par différentes applications qui exécutent les instructions SQL suivantes :

La transaction 2 exécute une instruction SQL qui utilise toutes les valeurs du champ f2. Ensuite, une nouvelle ligne est insérée dans la transaction 1, provoquant la réexécution de l'instruction SQL dans la transaction 2 pour produire un résultat différent. Cette situation est appelée lecture fantôme (lecture fantôme). Elle diffère de la lecture non répétable en ce que le résultat de l'accès répété aux données a changé non pas en raison de la modification/suppression des données elles-mêmes, mais en raison de l'apparition de nouvelles données (fantômes).