Transakcje to silny mechanizm, który umożliwia nam zachowanie prawidłowego przebiegu operacji z wykorzystaniem bazy danych. Przede wszystkim przybliżę Ci zasadę działania, a później pokażę parę przykładów w Spring Boot.
Transakcje w Spring – przykład
Rozpatrzmy to na przykładzie aplikacji do obsługi lotów:
- Rezerwujesz bilet lotniczy, podajesz imię i nazwisko.
- Przechodzisz do płatności, logujesz się do systemu bankowego i okazuje się, że nie masz wystarczająco pieniędzy by opłacić bilet.
I tu pojawia się problem ponieważ operacja 2 następuje po operacji 1. Więc w bazie danych pozostaną Twoje dane wraz zarezerwowanym biletem, który nigdy nie zostaje opłacony.
Działania te można uzależnić wykonując je w ramach transakcji. Wówczas w przypadku kiedy jakaś operacja w ramach transakcji nie powiedzie się wówczas zostanie przywrócony stan sprzed próby wykonania transakcji. Natomiast mechanizm przywracający stan sprzed próby wykonania transakcji nosi nazwę rollback.
I wykonuje się on w momencie, kiedy aplikacja napotka przeszkodę – najczęściej błąd, lub jak w naszym przypadku niewystarczająca ilość środków na koncie.
Podsumowując – wykonujemy operację 1, następnie operacje 2. Operacja 2 zakończyła się niepowodzeniem, a więc rollback przywraca stan sprzed operacji 1.
Jednak, aby w pełni zrozumieć celowość wykorzystania transakcji, to musimy wiedzieć czym jest ACID.
ACID – Gwarancja transakcji
Przede wszystkim ACID, to zbiór właściwości gwarantujących poprawne przetwarzanie transakcji w bazach danych. Natomiast jego nazwa to akronim od słów:
- Atomicity – gwarantuje, że każda transakcja jest traktowana jako jednostka i są one niepodzielne. Transakcja musi się wykonać w całości, albo w cale.
- Consistency – gwarantuje, że operacje na bazie danych nie naruszą spójności danych.
- Isolation – gwarancja, że każda transakcja musi być niezależna od drugiej.
- Durability – gwarantuje, że dane nie zostaną utracone np. w wyniku awarii.
Niedotrzymanie jeden z tych reguł grozi wystąpieniem problemów takich jak Dirty Read, Phantom Read lub Repeatable Read, a przykład takiego problemu możesz zobaczyć na moim krótkim video:
Izolacje Transakcji
W celu uniknięcia takich problemów jak Dirty Read, Phantom Read lub Repeatable Read wykorzystywany jest mechanizm izolacji transakcji, dostępne są:
- Read Committed
- Repeatable Read
- Serializable
Ponadto każda z izolacji rozwiązuje problem, lub grupę problemów a najlepiej to zobrazuje nam tabelka:
| Dirty reads | Non-repeatable reads | Phantom Read | |
| Read Committed | ✅ | ||
| Repeatable Read | ✅ | ✅ | |
| Serializable | ✅ | ✅ | ✅ |
Mimo, że poziom izolacji Serializable rozwiązuje wszystkie problemy to wykorzystywanie to wykorzystywać go powinnyśmy tylko w okolicznościach gdzie rzeczywiście istnieje zagrożenie pojawienia się tego problemu. Ponieważ im wyższy poziom izolacji tym wyższy koszt wykonywania się transakcji. Dlatego dobór poziomu wpływa na optymalizację.
Jak implementować transakcje izolacje i propagacje w Spring Boot?
O tym opowiadam na moim szkoleniu Spring Data – Transakcje, Izolacje i Propagacje, które jest dostępne dla osób wspierających mój kanał. Dlatego jeśli chcesz sprawnie nauczyć się korzystać z transakcji, to musisz go zobaczyć!
Tymczasem zachęcam Cię do obejrzenia fragmentu szkolenia w ramach, którego poruszam bardzo ważną kwestię – działanie mechanizmu Rollback For:
