Read commited е ниво на изолация, което гарантира, че всички прочетени данни са извършени в момента се чете. Той просто ограничава читателя да вижда каквото и да било междинно, необвързано, „мръсно“ четиво. Не обещава каквото и да е, че ако транзакцията повторно издаде прочетеното, ще намери същото данни, данните са свободни за промяна, след като бъдат прочетени.
Повторяемото четене е по-високо ниво на изолация, което в допълнение към гаранциите на нивото на ангажимент за четене също така гарантира, че всички прочетени данни не могат да се променят , ако транзакцията прочете отново същите данни, тя ще намери прочетените по-рано данни на място, непроменени и налични за четене.
Следващото ниво на изолация, което може да се сериализира, дава още по-силна гаранция:в допълнение към всичко повтарящо се четене, то също така гарантира, че няма ново данни може да се види при последващо четене.
Да кажем, че имате таблица T с колона C с един ред в нея, да кажем, че има стойността '1'. И помислете, че имате проста задача като следната:
BEGIN TRANSACTION;
SELECT * FROM T;
WAITFOR DELAY '00:01:00'
SELECT * FROM T;
COMMIT;
Това е проста задача, която издава две показания от таблица T, със закъснение от 1 минута между тях.
- в ПРОЧЕТЕНЕТО ИЗВЪРЗАНО, вторият SELECT може да върне всякак данни. Едновременна транзакция може да актуализира записа, да го изтрие, да вмъкне нови записи. Вторият избор винаги ще вижда новото данни.
- под REPEATABLE READ вторият SELECT гарантирано показва поне редовете, които са били върнати от първия SELECT непроменени . Нови редове могат да бъдат добавени чрез едновременна транзакция за тази една минута, но съществуващите редове не могат да бъдат изтрити или променени.
- под SERIALIZABLE чете вторият избор гарантирано ще види точно същите редове като първия. Нито един ред не може да бъде променян, нито изтриван, нито нови редове могат да бъдат вмъкнати чрез едновременна транзакция.
Ако следвате логиката по-горе, можете бързо да разберете, че SERIALIZABLE транзакции, въпреки че могат да улеснят живота ви, винаги напълно блокират всяка възможна едновременна операция, тъй като те изискват никой да не може да променя, изтрива или вмъква ред. Нивото на изолация на транзакциите по подразбиране на .Net System.Transactions обхватът може да се сериализира и това обикновено обяснява ужасната производителност, която се получава.
И накрая, има и ниво на изолация SNAPSHOT. Нивото на изолация на SNAPSHOT дава същите гаранции като сериализиращи се, но не като изисква нито една паралелна транзакция да може да променя данните. Вместо това принуждава всеки читател да види своя собствена версия на света (това е собствена „моментна снимка“). Това го прави много лесно за програмиране, както и много мащабируемо, тъй като не блокира едновременните актуализации. Това предимство обаче идва с цена:допълнителна консумация на ресурси на сървъра.
Допълнителното гласи:
- Нива на изолация в машината за база данни
- Ефекти на паралелност
- Избор на нива на изолация, базирани на версии на ред
