Problemy transakcji współbieżnych

1.1 Wprowadzenie

A teraz zaczyna się zabawa - teoria działania transakcji. Jak sprawić, by system działał, gdy zmieniasz te same dane w różnych wątkach? A może chcesz wykonać jedną transakcję w innej? Zaczniemy szukać odpowiedzi na te pytania, badając izolację transakcji ...

Poziom izolacji transakcji jest wartością warunkową określającą, w jakim stopniu w wyniku realizacji logicznie równoległych transakcji w SZBD dopuszczane są niespójne dane. Skala poziomów izolacji transakcji zawiera szereg wartości uszeregowanych od najniższej do najwyższej; wyższy poziom izolacji odpowiada lepszej spójności danych, ale jego użycie może zmniejszyć liczbę fizycznie równoległych transakcji.

I odwrotnie, niższy poziom izolacji pozwala na więcej transakcji równoległych, ale zmniejsza dokładność danych. Tym samym, wybierając zastosowany poziom izolacji transakcji, twórca systemu informatycznego w pewnym stopniu zapewnia wybór między szybkością pracy a zapewnieniem gwarantowanej spójności danych otrzymywanych z systemu.

Problemy współbieżnego dostępu z wykorzystaniem transakcji

Gdy transakcje są wykonywane równolegle, możliwe są następujące problemy:

• utracona aktualizacja - jeśli jeden blok danych zostanie zmieniony jednocześnie przez różne transakcje, wszystkie zmiany zostaną utracone, z wyjątkiem ostatniej;
• odczyt „brudny” (ang. Dirty read) - odczyt danych dodanych lub zmienionych transakcją, które następnie nie zostaną potwierdzone (wycofane);
• non-repeatable read (ang. non-repeatable read) - podczas ponownego odczytu w ramach tej samej transakcji, poprzednio odczytane dane ulegają zmianie;
• odczyty fantomowe - jedna transakcja podczas kilkukrotnego wykonania wybiera wiele wierszy według tych samych kryteriów. Inna transakcja pomiędzy tymi pobraniami dodaje wiersze lub modyfikuje kolumny niektórych wierszy użytych w kryteriach pobierania pierwszej transakcji i kończy się pomyślnie. W rezultacie okaże się, że te same wybory w pierwszej transakcji dają różne zestawy wierszy.

Rozważ sytuacje, w których mogą wystąpić te problemy.

1.2 Utracona aktualizacja

Sytuacja, w której, gdy jeden blok danych zostanie zmieniony jednocześnie przez różne transakcje, jedna ze zmian zostanie utracona.

Załóżmy, że w tym samym czasie odbywają się dwie transakcje:

W obu transakcjach zmienia się wartość pola f2, po zakończeniu wartość pola należy zwiększyć o 45. W rzeczywistości może wystąpić następująca sekwencja działań:

1. Obie transakcje jednocześnie odczytują aktualny stan pola. Dokładna fizyczna współbieżność nie jest tutaj wymagana, wystarczy, że druga w kolejności operacja odczytu zostanie zakończona, zanim kolejna transakcja zapisze swój wynik.
2. Obie transakcje obliczają nową wartość pola, dodając odpowiednio 20 i 25 do poprzednio odczytanej wartości.
3. Transakcje próbują zapisać wynik obliczeń z powrotem do pola f2. Ponieważ fizycznie niemożliwe jest jednoczesne wykonanie dwóch zapisów, w rzeczywistości jeden z operacji zapisu zostanie wykonany wcześniej, a drugi później. Druga operacja zapisu nadpisze wynik pierwszej.

W rezultacie wartość pola f2 po zakończeniu obu transakcji może wzrosnąć nie o 45, ale o 20 lub 25, czyli jedna z transakcji zmieniających dane „zniknie”.

1.3 „Brudny” odczyt

Odczyt danych dodanych lub zmodyfikowanych przez transakcję, których później nie uda się zatwierdzić (wycofanie).

Załóżmy, że mamy dwie transakcje otwarte przez różne aplikacje, które wykonują następujące instrukcje SQL:

W transakcji 1 zmieniana jest wartość pola f2, a następnie w transakcji 2 wybierana jest wartość tego pola. Następnie cofana jest transakcja 1. W rezultacie wartość otrzymana przez drugą transakcję będzie się różnić od wartości zapisanej w bazie danych.

1.4 Niepowtarzalny odczyt

Sytuacja, w której podczas ponownego odczytu w ramach tej samej transakcji, poprzednio odczytane dane okazują się być zmienione.

Załóżmy, że mamy dwie transakcje otwarte przez różne aplikacje, które wykonują następujące instrukcje SQL:

W transakcji 2 wybierana jest wartość pola f2, następnie w transakcji 1 zmieniana jest wartość pola f2. Jeśli spróbujesz ponownie wybrać wartość z pola f2 w transakcji 2, uzyskasz inny wynik. Taka sytuacja jest szczególnie niedopuszczalna, gdy dane są odczytywane w celu ich częściowej modyfikacji i ponownego zapisania do bazy danych.

1.5 Czytanie „fantomów”

Sytuacja, gdy podczas wielokrotnego odczytu w ramach tej samej transakcji ta sama selekcja daje różne zestawy wierszy.

Załóżmy, że istnieją dwie transakcje otwarte przez różne aplikacje, które wykonują następujące instrukcje SQL:

Transakcja 2 wykonuje instrukcję SQL, która wykorzystuje wszystkie wartości pola f2. Następnie w transakcji 1 wstawiany jest nowy wiersz, co powoduje, że ponowne wykonanie instrukcji SQL w transakcji 2 da inny wynik. Ta sytuacja nazywana jest czytaniem fantomowym (czytanie fantomowe). Różni się od odczytu niepowtarzalnego tym, że wynik wielokrotnego dostępu do danych zmienił się nie z powodu zmiany/usunięcia samych danych, ale z powodu pojawienia się nowych (fantomowych) danych.