• Article

Effet des accès concurrentiels

Les utilisateurs qui modifient des données peuvent interférer avec d'autres utilisateurs en train de lire ou de modifier les mêmes données en même temps. On dit que ces utilisateurs accèdent aux données de manière concurrentielle. Si un système de stockage de données est dépourvu de contrôle des accès concurrentiels, les utilisateurs peuvent constater les effets secondaires suivants :

  • Mises à jour perdues

  • Dépendance non validée (lecture erronée)

  • Analyse incohérente (lecture non reproductible)

  • Lectures fantômes.

  • Lectures manquantes et en double provoquées par des mises à jour de ligne

Mises à jour perdues

Les mises à jour perdues se produisent lorsque deux transactions ou plus sélectionnent la même ligne, puis la mettent à jour en fonction de la valeur qui s'y trouvait à l'origine. Aucune transaction n'a connaissance des autres transactions. La dernière mise à jour écrase les mises à jour effectuées par les autres transactions, ce qui entraîne une perte de données.

Exemple : deux éditeurs font une copie électronique du même document. Chaque éditeur modifie son document et l'enregistre ensuite, en écrasant le document original. Le dernier éditeur à avoir enregistré le document écrase les modifications effectuées par l'autre éditeur. Le problème pourrait être évité en empêchant un éditeur d'accéder au fichier tant que l'autre éditeur n'a pas terminé et validé la transaction.

Dépendance non validée (lecture incorrecte)

Une dépendance non validée se produit lorsqu'une deuxième transaction sélectionne une ligne qui est actuellement mise à jour par une autre transaction. La deuxième transaction lit les données qui n'ont pas encore été validées et qui peuvent être modifiées par la transaction de mise à jour de la ligne.

Supposons par exemple qu'un éditeur effectue des modifications dans un document électronique. Pendant les modifications, un second éditeur fait une copie du document comprenant toutes les modifications effectuées jusqu'alors et distribue ce dernier aux destinataires concernés. Le premier éditeur décide alors que les modifications effectuées sont incorrectes, les supprime et enregistre le document. Le document qui a été distribué comprend donc des modifications qui n'existent plus et devraient être traitées comme si elles n'avaient jamais existé. Le problème pourrait être évité en interdisant la lecture du document modifié tant que le premier éditeur n'a pas effectué l'enregistrement final des modifications et validé la transaction.

Analyse incohérente (lecture non renouvelable)

Une analyse incohérente se produit lorsqu'une deuxième transaction accède à la même ligne plusieurs fois et lit différentes données à chaque fois. Une analyse incohérente est similaire à une dépendance non validée en ce sens qu'une autre transaction change les données qu'une deuxième transaction est en train de lire. Cependant, dans une analyse incohérente, les données lues par la deuxième transaction sont validées par la transaction qui a effectué la modification. En outre, une analyse incohérente implique plusieurs lectures (deux ou plus) de la même ligne dont les informations sont systématiquement modifiées par une autre transaction, d'où l'expression de lecture non renouvelable.

Par exemple, un éditeur relit le même document deux fois, mais l'auteur réécrit le document entre les relectures. Lorsque l'éditeur relit le document pour la seconde fois, le document a changé. La relecture initiale n'est donc pas renouvelable. Ce problème pourrait être évité si l'auteur ne pouvait pas modifier le document tant que l'éditeur n'a pas terminé la dernière lecture.

Lectures fantômes

Des lectures fantômes se produisent lorsqu'une action d'insertion ou de suppression a été effectuée sur une ligne appartenant à une plage de lignes en cours de lecture par une transaction. La première lecture par la transaction de la plage de lignes indique une ligne qui n'existe plus dans la deuxième lecture ou les lectures suivantes à la suite d'une suppression par une autre transaction. De même, à la suite d'une insertion par une autre transaction, la deuxième lecture ou la lecture suivante de la transaction indique une ligne qui n'existait pas dans la lecture d'origine.

Exemple : un éditeur modifie un document soumis par un auteur. Lorsque les modifications sont incorporées dans le document original par la rédaction, on découvre que des éléments nouveaux et non approuvés par l'éditeur ont été ajoutés au document par l'auteur. Au même titre que la situation de la lecture non renouvelable, ce problème pourrait être évité si personne ne pouvait ajouter de nouveaux éléments au document tant que l'éditeur et la rédaction n'ont pas fini de travailler sur le document d'origine.

Lectures manquantes et en double provoquées par des mises à jour de ligne

  • Manquer une ligne mise à jour ou consulter une ligne mise à jour plusieurs fois

    Les transactions qui s'exécutent au niveau READ UNCOMMITTED ne génèrent pas de verrous partagés pour empêcher d'autres transactions de modifier des données lues par la transaction en cours. Les transactions qui s'exécutent au niveau READ COMMITTED génèrent des verrous partagés, mais les verrous de ligne ou de page sont libérés une fois la ligne lue. Dans les deux cas, lorsque vous analysez un index, si un autre utilisateur modifie la colonne de clé d'index de la ligne pendant votre lecture, la ligne peut apparaître de nouveau si la modification apportée à la clé a déplacé la ligne à une position située en aval de votre analyse. De même, la ligne peut ne pas apparaître si la modification apportée à la clé a déplacé la ligne à une position dans l'index que vous aviez déjà lue. Pour éviter cela, utilisez l'indicateur SERIALIZABLE ou HOLDLOCK ou la gestion des versions de ligne. Pour plus d'informations, consultez Indicateurs de table (Transact-SQL) et Niveaux d'isolation basés sur les versions de lignes dans le moteur de base de données.

  • Manquer une ou plusieurs lignes qui n'étaient pas la cible de la mise à jour

    Lorsque vous utilisez READ UNCOMMITTED, si votre requête lit des lignes à l'aide d'une analyse d'ordre d'allocation (à l'aide de pages IAM), vous risquez de manquer des lignes si une autre transaction provoque un fractionnement de page. Cela ne peut pas se produire lorsque vous utilisez la lecture validée car un verrou de table est maintenu pendant un fractionnement de page et ne se produit pas si la table n'a pas d'index cluster, car les mises à jour ne provoquent pas de fractionnements de page.