Powtarzalny Odczyt

Stan bazy danych jest utrzymywany od początku transakcji. Jeśli odzyskasz wartość w session1, zaktualizuj ją w session2, a odzyskanie jej ponownie w session1 zwróci te same wyniki. Odczyty są powtarzalne.

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

Czytaj

W kontekście transakcji zawsze pobierasz ostatnio zatwierdzoną wartość. Jeśli pobierasz wartość w session1, zaktualizuj ją w session2, a następnie pobierz ją w session1again, otrzymasz wartość zmodyfikowaną w session2. Czyta ostatni wiersz.

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

Po prostu odpowiedź według mojego czytania i zrozumienia do tego wątku i @remus-rusanu odpowiedź opiera się na tym prostym scenariuszu:

Istnieją dwa procesy A I B. Proces B to odczyt tabeli X Proces A zapisuje się w tabeli X Proces B odczytuje ponownie tabelę X.

• ReadUncommitted : Proces B może odczytywać niezatwierdzone dane z procesu a i może widzieć różne wiersze na podstawie zapisu B. No lock at all
• ReadCommitted : Proces B może odczytywać tylko zatwierdzone dane z procesu A i może widzieć różne wiersze na podstawie zatwierdzonego tylko zapisu B. możemy to nazwać prostym zamkiem?
• RepeatableRead : Proces B będzie odczytywał te same dane (wiersze) niezależnie od tego, co robi proces A. Ale proces A może zmieniać inne wiersze. Rows level Block
• Serializowalny: Proces B będzie odczytywał te same wiersze, co wcześniej, a proces A nie może odczytywać ani zapisywać w tabeli. Poziom tabeli Blok
• Snapshot : każdy proces ma swoją własną kopię i pracuje nad nią. Każdy ma swój własny widok

Stare pytanie, które ma już zaakceptowaną odpowiedź, ale lubię myśleć o tych dwóch poziomach izolacji pod kątem tego, jak zmieniają zachowanie blokowania w SQL Server. Może to być pomocne dla tych, którzy debugują martwe punkty, jak ja.

READ COMMITTED (default)

Współdzielone blokady są pobierane w SELECT, a następnie zwalniane Po zakończeniu instrukcji SELECT. W ten sposób system może zagwarantować, że nie ma brudnych odczytów niezarejestrowanych danych. Inne transakcje mogą nadal zmieniać wiersze bazowe po zakończeniu SELECT i przed zakończeniem transakcji.

POWTARZALNY ODCZYT

Współdzielone blokady są pobierane w SELECT, a następnie zwalniane dopiero po zakończeniu transakcji . W ten sposób system może zagwarantować, że odczytane wartości nie zmienią się podczas transakcji (ponieważ pozostają zablokowane do momentu zakończenia transakcji).

Próbuje wyjaśnić tę wątpliwość prostymi diagramami.

Read Committed: tutaj na tym poziomie izolacji transakcja T1 będzie odczytywała zaktualizowaną wartość X committed przez transakcję T2.

Powtarzalny odczyt: na tym poziomie izolacji transakcja T1 nie będzie uwzględniała zmian popełnionych przez transakcję T2.

Moje spostrzeżenie na temat wstępnego zaakceptowanego rozwiązania.

Under RR (default mysql) - jeśli tx jest otwarty i SELECT został wywołany, inny tx nie może usunąć żadnego wiersza należącego do poprzedniego zestawu wyników odczytu, dopóki poprzedni TX nie zostanie zatwierdzony (w rzeczywistości polecenie delete w nowym tx będzie po prostu zawieszone), jednak następny tx może usunąć wszystkie wiersze z tabeli bez żadnych problemów. Btw, następny odczyt w poprzednim tx będzie nadal widział stare dane, dopóki nie zostaną zatwierdzone.