Lecture sale, lecture fantôme, lecture non répétable et instances de mise à jour perdues

Le 5 juin 2017, le temps était pluvieux.

Lorsque je triais mes notes d'étude précédentes il y a deux jours, j'ai trouvé que les problèmes causés par la simultanéité des transactions - lectures sales, lectures fantômes, lectures non répétables et mises à jour perdues étaient un peu vagues, j'ai donc examiné à nouveau, et maintenant j’ai résumé certaines de mes compréhensions comme suit pour la commodité de tous.

Le verrouillage est un moyen d'empêcher d'autres transactions d'accéder à des ressources spécifiées. Les verrous constituent la principale méthode permettant de contrôler la concurrence et constituent une garantie importante permettant à plusieurs utilisateurs de pouvoir manipuler les données de la même base de données en même temps sans incohérence des données. De manière générale, les verrous empêchent les lectures incorrectes, les lectures non répétables et les lectures fantômes.

1.Dirty Read——Une transaction lit des données qu'une autre transaction n'a pas validées.

Explication détaillée : lorsqu'une transaction accède aux données et les modifie, mais que la modification n'a pas encore été soumise à la base de données, une autre transaction accède également aux données et utilise ensuite les données. Étant donné que ces données n'ont pas encore été validées, les données lues par une autre transaction sont des données sales et les opérations basées sur ces données sales peuvent être incorrectes.

Transaction T1 : Mettre à jour une donnée
-->Transaction T2 : Lire l'enregistrement mis à jour par la transaction T1
Transaction T1 : Appeler le commit pour soumettre
À ce moment, la transaction T2 lit Les données sont des données stockées dans la mémoire de la base de données, appelées données sales. Ce processus est appelé lecture sale.

Une lecture sale se produit lorsqu'une transaction A lit des données qui ont été modifiées par une autre transaction B mais qui n'ont pas encore été validées. Si B revient en arrière, la transaction A lit des données invalides. Ceci est similaire à une lecture non répétable, mais la deuxième transaction n'a pas besoin d'être validée.

Résolvez le problème de lecture sale : ajoutez un verrou exclusif lors de la modification et relâchez-le jusqu'à ce que la transaction soit validée. Ajoutez un verrou partagé lors de la lecture, libérez la transaction 1 et ajoutez un verrou partagé lors de la lecture des données (donc). qu'après la transaction 1 Pendant le processus de lecture des données, les autres transactions ne modifieront pas les données), aucune transaction n'est autorisée à opérer sur les données, elles ne peuvent être lues qu'après 1, s'il y a une opération de mise à jour, elle le sera. converti en verrou exclusif, et les autres transactions n'auront aucun droit de participer à la lecture et à l'écriture, évitant ainsi les problèmes de lecture sale. Cependant, lorsque la transaction 1 lit les données, il est possible que d'autres transactions aient également lu les données. Une fois la lecture terminée, le verrou partagé est libéré. ​​À ce moment, la transaction 1 modifie les données. la transaction est soumise.Lorsque d'autres transactions lisent à nouveau les données, elles trouvent les données si elles sont incohérentes, des problèmes de lecture non répétables se produiront, cela ne peut donc pas éviter des problèmes de lecture non répétables.

2.Lecture fantôme (Phantom)——Dans la même transaction, la même opération est utilisée pour lire deux fois, et le nombre d'enregistrements obtenus est différent.

Explication détaillée : La lecture fantôme fait référence à un phénomène qui se produit lorsque les transactions ne sont pas exécutées indépendamment. Par exemple, la première transaction modifie les données d'une table, et cette modification implique toutes les données de la table. Parallèlement, la deuxième transaction modifie également les données de cette table. Cette modification insère une ligne de nouvelles données dans la table. Ensuite, à l’avenir, l’utilisateur qui effectue la première transaction constatera qu’il reste des lignes de données non modifiées dans la table, comme si une hallucination s’était produite.

Transaction T1 : Interroger tous les enregistrements de la table
                                                                                                                                                                                                             ; Tous les enregistrements ;
dans
A ce moment, les enregistrements interrogés deux fois par la transaction T1 sont différents, ce qu'on appelle une lecture fantôme.

Remarque : la lecture fantôme se concentre sur l'ajout ou la suppression.

La lecture fantôme se produit lorsque deux requêtes identiques sont exécutées et que l'ensemble de résultats renvoyé par la deuxième requête est différent de la première requête.

Que se passe-t-il : Pas de verrouillage de la lunette.

Comment éviter : implémentez le mode d'isolation par sérialisation, ce qui peut se produire dans n'importe quelle isolation de bas niveau.

Résoudre le problème de lecture fantôme : le mode de verrouillage de plage RangeS RangeS_S est utilisé pour verrouiller la plage de recherche en lecture seule, évitant ainsi le problème de lecture fantôme.

3.

Lecture non répétable

——Dans la même transaction, les mêmes données sont lues deux fois et le contenu est différent. Transaction T1 : Interroger un enregistrement

                                                                                                                                                                                                                        . Le dernier enregistrement

À ce moment, la transaction T1 interroge deux fois les mêmes données et le contenu disponible est différent, ce qui est dit non répétable. lire.


Remarque : la lecture non répétable se concentre sur la modification.

Dans la méthode de contrôle parallèle basée sur le verrouillage, si un verrou de lecture n'est pas ajouté lors de l'exécution de la sélection, un problème de lecture non répétable se produira. Dans le mécanisme de contrôle parallèle multi-versions, lorsqu'une transaction qui rencontre un conflit de validation doit être annulée mais est publiée, un problème de lecture non reproductible se produit.

Il existe deux stratégies pour éviter que ce problème ne se produise :

(1) Différer l'exécution de la transaction 2 jusqu'à ce que la transaction 1 soit validée ou annulée. Cette stratégie s'applique lors de l'utilisation de verrous.

(2) Dans le contrôle parallèle multiversion, la transaction 2 peut être soumise en premier, tandis que la transaction 1 continue de s'exécuter sur l'ancienne version des données. Lorsque la transaction 1 tente enfin d'être validée, la base de données vérifie si son résultat est le même que lorsque la transaction 1 et la transaction 2 ont été exécutées séquentiellement. Si oui, la transaction 1 est soumise avec succès ; sinon, la transaction 1 sera annulée.

Résolvez le problème de lecture non reproductible : ajoutez des verrous partagés lors de la lecture des données, ajoutez des verrous exclusifs lors de l'écriture des données et libérez les verrous uniquement après la soumission de la transaction. Aucune autre chose n'est autorisée à modifier les données lors de la lecture. Quel que soit le nombre de fois que les données sont lues au cours de la transaction, les données sont cohérentes, évitant ainsi le problème de lecture non répétable.
4.Mise à jour perdue (Mise à jour perdue)

La transaction T1 lit les données, effectue certaines opérations, puis met à jour les données. La transaction T2 fait également la même chose : lorsque T1 et T2 mettent à jour les données, ils peuvent écraser les mises à jour de chacun, provoquant des erreurs.

5. Pour résoudre les problèmes de niveau d'isolement ci-dessus, utilisez la méthode suivante :

Cinq niveaux d'isolement des transactions :
(1) TRANSACTION_NONE n'utilise pas de transactions.
(2) TRANSACTION_READ_UNCOMMITTED autorise les lectures sales.
(3) TRANSACTION_READ_COMMITTED empêche les lectures sales, le niveau d'isolement le plus couramment utilisé, et constitue le niveau d'isolement par défaut pour la plupart des bases de données.
(4) TRANSACTION_REPEATABLE_READ peut empêcher les lectures sales et les lectures non répétables.
(5) TRANSACTION_SERIALIZABLE peut empêcher les lectures sales, les lectures non répétables et les lectures fantômes, ce qui (sérialisation des transactions) réduira l'efficacité de la base de données.

Les cinq niveaux d'isolement des transactions ci-dessus sont des constantes statiques définies dans l'interface de connexion. Utilisez la méthode setTransactionIsolation(int level) pour définir le niveau d'isolement des transactions.

Par exemple : con.setTransactionIsolation(Connection.REPEATABLE_READ).

Remarque : Le niveau d'isolement d'une transaction est limité par la base de données. Les niveaux d'isolement pris en charge par les différentes bases de données ne sont pas nécessairement les mêmes.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!