Je pense que le au-dessus des niveaux d'isolement sont tellement semblables. Quelqu'un pourrait-il décrire avec quelques beaux exemples quelle est la principale différence ?
Réponses
Trop de publicités?
Read committed est un niveau d'isolement qui garantit que toutes les données en lecture a été commis au moment de la lecture. Il restreint le lecteur de voir un intermédiaire, non validées, 'sale'. IL ne fait pas de promettre que si l'opération de re-les enjeux de la lecture, trouverez Même des données, de données est libre de changer après qu'il a été lu.
Repeatable read est d'un plus haut niveau d'isolation, qu'en plus de la garantie de la lecture engagée niveau, il garantit également que les données lues ne peut pas changer, si la transaction se lit à nouveau les mêmes données, il va trouver le lire précédemment, inchangé, et disponible à la lecture.
Le prochain niveau d'isolation serializable, rend encore plus forte garantie: en plus de tout repeatable read garanties, il garantit également que pas de nouvelles données peuvent être vus par une lecture ultérieure.
Disons que vous avez un tableau T avec une colonne C avec une rangée, dire qu'il a la valeur '1'. Et de considérer 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 émettent des deux lectures de la table T, avec un retard de 1 minute entre eux.
- en vertu de LIRE la partie prenante, la deuxième sélection peut retourner toutes les données. Une transaction simultanée peut mettre à jour le dossier, supprimer, insérer de nouveaux enregistrements. La deuxième sélection aura toujours voir les nouvelles données.
- en vertu de LECTURE répétée de la deuxième sélection est la garantie de voir les lignes qui en a vu d'abord sélectionner inchangé. De nouvelles lignes peuvent être ajoutées par une transaction simultanée dans une minute, mais les lignes existantes ne peuvent pas être supprimés ni modifiés.
- en vertu de SERIALIZABLE lit la deuxième sélection est garanti de voir exactement les mêmes lignes que le premier. Pas de ligne peut changer, ni supprimé, ni de nouvelles lignes peuvent être insérées par une transaction simultanée.
Si vous suivez la logique ci-dessus, vous pouvez rapidement compte que les transactions SÉRIALISABLES, alors qu'ils peuvent rendre la vie facile pour vous, sont toujours complètement le blocage de tous les simultanés possibles de l'opération, puisqu'elles exigent que personne ne peut les modifier, les supprimer, ni insérer une ligne. La transaction par défaut isolationlevel de la .Net System.Transactions portée est sérialisable, et généralement, ceci explique l'insondable de la performance qui en résulte.
Et enfin, il y a aussi le niveau d'isolation SNAPSHOT. Le niveau d'isolation SNAPSHOT fait les mêmes garanties que serializable, mais pas en exigeant qu'aucune transaction simultanée pouvez modifier les données, mais par tout lecteur de voir sa propre version du monde (c'est du propre "instantané"). Cela rend très facile à programmer par contre, très évolutive que de ne pas bloquer les mises à jour simultanées, mais bien sûr, cela a un prix, et le prix est extra consommation des ressources du serveur.
Complémentaire de lit:
Hazel_arun
Points
326
Repeatable Read
L'état de la base de données est maintenue depuis le début de la transaction. Si vous récupérer une valeur dans session1, puis mettre à jour la valeur dans session2, le récupérer à nouveau dans session1 vous obtiendrez les mêmes résultats. Les lectures sont reproductibles.
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
Read Committed
Dans le contexte d'une transaction, vous pourrez toujours récupérer le plus récent de la valeur d'engagement. Si vous récupérer une valeur dans session1, le mettre à jour dans session2, puis de les récupérer dans session1again, vous obtenez la valeur, telle que modifiée en 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
Du sens?
