La lecture validée est un niveau d'isolement qui garantit que toutes les données lues ont été validées en ce moment est lu. Cela empêche simplement le lecteur de voir toute lecture intermédiaire, non validée et « sale ». Il ne fait aucune promesse que si la transaction réémet la lecture, trouvera le Same données, les données sont libres de changer après avoir été lues.
La lecture répétable est un niveau d'isolement plus élevé qui, en plus des garanties du niveau de lecture validé, garantit également que toutes les données lues ne peuvent pas changer , si la transaction lit à nouveau les mêmes données, elle retrouvera les données précédemment lues en place, inchangées et disponibles en lecture.
Le niveau d'isolement suivant, sérialisable, offre une garantie encore plus forte :en plus de toutes les garanties de lecture reproductibles, il garantit également qu'aucun nouveau données peut être vu par une lecture ultérieure.
Disons 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 celle-ci :
BEGIN TRANSACTION;
SELECT * FROM T;
WAITFOR DELAY '00:01:00'
SELECT * FROM T;
COMMIT;
C'est une tâche simple qui émet deux lectures à partir de la table T, avec un délai d'une minute entre elles.
- sous READ COMMITTED, le deuxième SELECT peut renvoyer any Les données. Une transaction simultanée peut mettre à jour l'enregistrement, le supprimer, insérer de nouveaux enregistrements. La deuxième sélection verra toujours le nouveau données.
- sous REPEATABLE READ, le deuxième SELECT est garanti pour afficher au moins les lignes renvoyées par le premier SELECT inchangé . De nouvelles lignes peuvent être ajoutées par une transaction simultanée pendant cette minute, mais les lignes existantes ne peuvent pas être supprimées ni modifiées.
- sous SERIALIZABLE lit la deuxième sélection garantie de voir exactement les mêmes rangées que la première. Aucune ligne ne peut être modifiée, ni 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 pouvez rapidement réaliser que les transactions SERIALIZABLE, bien qu'elles puissent vous faciliter la vie, sont toujours bloquantes complètement toutes les opérations simultanées possibles, car elles nécessitent que personne ne puisse modifier, supprimer ou insérer une ligne. Le niveau d'isolement des transactions par défaut du .Net System.Transactions la portée est sérialisable, et cela explique généralement les performances abyssales qui en résultent.
Et enfin, il y a aussi le niveau d'isolation SNAPSHOT. Le niveau d'isolement SNAPSHOT offre les mêmes garanties que sérialisable, mais pas en exigeant qu'aucune transaction concurrente ne puisse modifier les données. Au lieu de cela, il force chaque lecteur à voir sa propre version du monde (c'est son propre « instantané »). Cela le rend très facile à programmer et 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 serveur.
Lectures supplémentaires :
- Niveaux d'isolement dans le moteur de base de données
- Effets de simultanéité
- Choisir des niveaux d'isolement basés sur la gestion des versions de ligne
