Différence entre read commit et readable read
Je pense que les niveaux d'isolement ci-dessus sont si semblables. Quelqu'un pourrait-il décrire, avec quelques exemples intéressants, quelle est la principale différence?
Lecture validée est un niveau d'isolation qui garantit que toute lecture de données était validée au moment de la lecture. Cela empêche simplement le lecteur de voir toute lecture intermédiaire, non validée, "sale". Le service informatique ne fait aucune promesse que si la transaction réémet la lecture, trouvera les données Same, les données sont libres de changer après avoir été lues.
La lecture répétable est un niveau d'isolation supérieur. Outre les garanties du niveau de lecture validée, elle garantit également que toutes les données lues ne peuvent pas changer, si la transaction lit à nouveau les mêmes données, elle retrouvera la valeur précédente. lire les données en place, inchangées et disponibles à la lecture.
Le niveau d'isolement suivant, sérialisable, renforce encore la garantie: outre les garanties de lecture répétées, il garantit également que no new data peut être visualisé lors d'une lecture ultérieure.
Supposons que vous avez une table T avec une colonne C avec une ligne, disons qu'elle a la valeur '1'. Et considérez que vous avez une tâche simple comme suit:
BEGIN TRANSACTION;
SELECT * FROM T;
WAITFOR DELAY '00:01:00'
SELECT * FROM T;
COMMIT;
C’est une tâche simple qui émet deux lectures du tableau T, avec un délai de 1 minute entre elles.
- sous READ COMITTED, le deuxième SELECT peut renvoyer des données indifférentes. Une transaction simultanée peut mettre à jour l'enregistrement, le supprimer, insérer de nouveaux enregistrements. La seconde sélection verra toujours les données nouvelles.
- sous REPEATABLE READ, le second SELECT est sûr de voir les lignes qui ont vu au début sélectionner inchangé. De nouvelles lignes peuvent être ajoutées par une transaction simultanée en une minute, mais les lignes existantes ne peuvent être ni supprimées ni modifiées.
- sous SERIALIZABLE lit, la deuxième sélection a la garantie de voir exactement les mêmes lignes que la première. Aucune ligne ne peut changer, ni être supprimée, ni de nouvelles lignes ne peuvent être insérées par une transaction simultanée.
Si vous suivez la logique ci-dessus, vous vous rendrez vite compte que les transactions SERIALIZABLE, bien qu'elles puissent vous simplifier la vie, sont toujours complètement bloquantes toutes les opérations simultanées possibles, car elles nécessitent que personne ne puisse les modifier, les supprimer ni les insérer. rangée. Le niveau d'isolation de transaction par défaut de la portée .Net System.Transactions est sérialisable, ce qui explique généralement les performances catastrophiques qui en résultent.
Et enfin, il y a aussi le niveau d'isolation SNAPSHOT. Le niveau d’isolation SNAPSHOT offre les mêmes garanties que les options sérialisables, mais pas en exigeant qu’aucune transaction simultanée ne puisse modifier les données. Au lieu de cela, il oblige chaque lecteur à voir sa propre version du monde (son propre "instantané"). Ceci facilite la programmation et est très évolutif, car il ne bloque pas les mises à jour simultanées. Cependant, cet avantage a un prix: une consommation supplémentaire de ressources du serveur.
Lit supplémentaire:
Lecture répétable
L'état de la base de données est conservé depuis le début de la transaction. Si vous récupérez une valeur dans session1, puis mettez à jour cette valeur dans session2, la récupérer à nouveau dans session1 renverra les mêmes résultats. Les lectures sont répétables.
session1> BEGIN;
session1> SELECT firstname FROM names WHERE id = 7;
Aaron
session2> BEGIN;
session2> SELECT firstname FROM names WHERE id = 7;
Aaron
session2> UPDATE names SET firstname = 'Bob' WHERE id = 7;
session2> SELECT firstname FROM names WHERE id = 7;
Bob
session2> COMMIT;
session1> SELECT firstname FROM names WHERE id = 7;
Aaron
Lire commis
Dans le contexte d'une transaction, vous récupérerez toujours la dernière valeur validée. Si vous récupérez une valeur dans session1, mettez-la à jour dans session2, puis récupérez-la dans session1again, vous obtiendrez la valeur modifiée dans session2. Il lit la dernière ligne validée.
session1> BEGIN;
session1> SELECT firstname FROM names WHERE id = 7;
Aaron
session2> BEGIN;
session2> SELECT firstname FROM names WHERE id = 7;
Aaron
session2> UPDATE names SET firstname = 'Bob' WHERE id = 7;
session2> SELECT firstname FROM names WHERE id = 7;
Bob
session2> COMMIT;
session1> SELECT firstname FROM names WHERE id = 7;
Bob
Logique?
La réponse selon ma lecture et ma compréhension de ce fil et la réponse de @ remus-rusanu est basée sur ce scénario simple:
Il y a deux processus A et B. Le processus B lit le tableau X .__ Le processus A écrit dans le tableau X .__ Le processus B lit à nouveau le tableau X.
- ReadUncommitted : Le processus B peut lire des données non validées à partir du processus A et il peut voir différentes lignes en fonction de l'écriture par B. Pas de verrou du tout
- ReadCommitted : Le processus B peut lire UNIQUEMENT les données validées du processus A et il peut voir des lignes différentes en fonction de l'écriture COMMITTED uniquement B. pourrions-nous l'appeler Simple Lock?
- RepeatableRead : Le processus B lira les mêmes données (lignes), peu importe le processus A. Mais le processus A peut changer d'autres lignes. Niveau des lignes Bloc
- Serialisable : Process B lira les mêmes lignes qu'avant et Process A ne pourra ni lire ni écrire dans la table. Bloc au niveau de la table
- Snapshot : chaque processus a sa propre copie et ils y travaillent. Chacun a sa propre vision
Ancienne question qui a déjà une réponse acceptée, mais j'aime bien penser à ces deux niveaux d'isolement en termes de modification du comportement de verrouillage dans SQL Server. Cela pourrait être utile pour ceux qui déboguent des impasses comme moi.
READ COMMITTED (par défaut)
Les verrous partagés sont pris dans SELECT, puis libérés lorsque l'instruction SELECT est terminée . C’est ainsi que le système peut garantir qu’il n’y aura pas de lectures modifiées de données non validées. D'autres transactions peuvent toujours modifier les lignes sous-jacentes après la fin de votre SELECT et avant la fin de votre transaction.
REPEATABLE READ
Les verrous partagés sont pris dans le SELECT, puis libérés uniquement une fois la transaction terminée . C'est ainsi que le système peut garantir que les valeurs que vous lisez ne changeront pas pendant la transaction (car elles restent verrouillées jusqu'à la fin de la transaction).
Essayer d'expliquer ce doute avec des schémas simples.
Read Committed: Ici, dans ce niveau d'isolement, la transaction T1 lira la valeur mise à jour du X validé par la transaction T2.
Lecture répétable: Dans ce niveau d'isolement, la transaction T1 ne tiendra pas compte des modifications validées par la transaction T2.
S'il vous plaît noter que, le répétable dans reproductibles lire à un tuple, mais pas à la table entière. Dans les niveaux d'isolement ANSC, lecture fantôme anomalie peut se produire, ce qui signifie lire une table avec la même clause, où deux fois peuvent renvoyer différents ensembles de résultats. Littéralement, ce n'est pas reproductible .
Je pense que cette image peut aussi être utile, elle me sert de référence lorsque je veux me rappeler rapidement les différences entre les niveaux d’isolement (grâce à kudvenkat sur youtube)
