По-долу е изявлението, написано от статията за изолацията в Wikipedia относно REPEATABLE READS
В това ниво на изолация внедряването на СУБД за управление на едновременност, базирано на заключване, поддържа заключвания за четене и запис (придобити върху избрани данни) до края на транзакцията. Заключванията на обхват обаче не се управляват, така че може да възникне феноменът на фантомните четения (вижте по-долу).
Въпросът ми тук е съответно кога започва и приключва транзакцията.
Ако вземем примера на Неповторими четения с ниво на изолация REPEATABLE READS на същата връзка, според моето разбиране trnsaction 1 започва, когато се задейства първата заявка, т.е. SELECT * FROM users WHERE id = 1.
DBMS ще запази заключването на потребителската таблица, докато и освен ако транзакцията не приключи. тук Покрай имам предвид, когато връзката бъде върната назад или не е ангажирана при завършване на SELECT * FROM users WHERE id = 1
. Дотогава транзакция 2 ще чака, нали?
Въпрос 2: - Сега, ако разгледаме нивото на изолация и тяхното поведение, както е дадено по-долу (на същата връзка)
Isolation level Dirty reads Non-repeatable Phantoms
Read Uncommitted may occur may occur may occur
Read Committed - may occur may occur
Repeatable Read - may occur -
Serializable - - -
Според моето разбиране най-надеждният е Serializable, след това Repeatable Read и след това Read Committed, но все пак съм виждал приложения, използващи Read Committed. Дали поради производителността на Serializable и Repeatable Read е лошо в сравнение с Read Committed, защото в сериализуемото ще бъде последователно и в случай на транзакция трябва да изчака освобождаването на заключването от друга транзакция. Нали? Така че, за да получим най-доброто от трите, можем да използваме ниво на изолация като Read Committed с SELECT FOR UPDATE
(за постигане на повтарящо се четене).Не сме сигурни как можем да постигнем фантомно четене, ако искаме, в случай на ниво на изолация на четене?
SELECT ... FOR UPDATE
- person Gili   schedule 29.11.2012