W poprzednim artykule została omówiona izolacja transakcji Read Commited w Oracle. W dzisiejszym artykule zajmę się przedstawieniem izolacji transakcji Serializable również na przykladzie Oracle.
1. Poziomy izolacji ogólny pogląd.
Przypomnijmy sobie tabelkę ze zestawieniem wszystkich izolacji i ich problemów jakie mogą powstać.
2.1 Serializable – Phantom Read.
Ten typ izolacji jest najbardziej restrykcyjny ze wszystkich. Tutaj transakcje ustawiają się w kolejce i czekają aż transakcja przed nimi się zakończy albo poprzez commit albo poprzez rollback. Jak widać powyżej wszystkie problemy zostały rozwiązane. Jednak wiążę się to ze spadkiem wydajności pracy bazy danych. Zobaczmy to więc na przykładzie.
Zarówno w sesji nr.1 jak i sesji nr.2 ustawiłam izolacje na serializable. Pobrałam aktualny stan tabeli employees, sprawdziłam czas. Następnie w sesji nr.1 przystąpiłam do modyfikacji tabeli poprzez wstawianie nowego pracownika z id = 6.
Następnie odczytałam dane w sesji nr.2 które na tym etapie są identyczne z danymi w sesij nr.1.
Jak możemy zobaczyć poniżej nie zatwierdzona transakcja nie jest widoczna w sesji nr.2. Jak do tej pory wszystko przebiega podobnie do isolation_level = Read commited. Jednak po zatwierdzeniu transakcji w sesji nr.1 i ponownym sprawdzeniu bazy w sesji nr.2 dalej nie widzimy dodanego pracownika z id = 6. Dzieje się tak ponieważ w sesji nr.2 nie skończyliśmy transakcji odczytu i dlatego zakończenie transakcji w sesji nr.1 nie aktualizuje nam informacji w sesji nr.2. Wynika to z faktu że operacja wstawienia dodatkowego wiersza (sesja nr.1) była by fantomem (phantom read) w sesji nr.2 a to na poziomie serializable jest niedozwolone. Dlatego też koniecznym jest zakończenie bieżącej operacji w sesji nr.2 np. wpisując commit i ponowne odczytanie danych w nowej transakcji.
2.2 Serializable – Non Reapatable Read.
Podobnie sytuacja wygląda w przypadku Non Repeatable Read. Aby aktualizacja danych pomiędzy sesjami była możliwa obie sesje powinny zostać zakończone. Przykładowo dokonujemy zmian na rekordzie danych o id =6.
Następnie zanim zatwierdzimy zmiany sprawdzamy stan danych w sesji nr. 2. Jak możemy zobaczyć poniżej zmiany nie są jeszcze widoczne.
Następnie dopiero po zakończeniu transakcji w obu sesjach zmiany są widoczne w sesji nr.2
3. Podsumowanie.
W dzisiejszym artykule nauczyliśmy że Serializable wszystko odbywa się według kolejności. I choć jest to skuteczny sposób na rozwiązanie problemów: Phantom Read i Non Reapatable Read to jednak może to prowadzić do spadku wydajności bazy danych. Pojawić się tutaj może również zjawisko deedlock. Jednak o tym w jednym z kolejnych artykułów. A jakie Ty tym masz doświadczenia z tego typu operacjami? Koniecznie podziel się w komentarzu 🙂 !