Procedura z transakcją

Procedura z transakcją zapewnia, że jej operacje zostaną albo wszystkie zatwierdzone, albo wszystkie wycofane.

Atomowość operacji wykonywanych przez procedurę

Procedura z transakcją to procedura składowana albo inny blok logiki wykonywany po stronie systemu zarządzania bazą danych, w którym kilka powiązanych operacji traktuje się jako jeden spójny proces. Transakcja wyznacza granice zmian: po jej rozpoczęciu wykonywane instrukcje mogą modyfikować wiele tabel, rekordów lub indeksów, ale rezultat staje się trwały dopiero po zatwierdzeniu. Jeżeli którykolwiek etap zakończy się błędem, całość może zostać wycofana do stanu sprzed rozpoczęcia transakcji.

Najważniejszą właściwością jest atomowość, czyli zasada „wszystko albo nic”. Przykładem może być przeniesienie środków pomiędzy dwoma rachunkami. Operacja obejmuje zmniejszenie salda pierwszego rachunku i zwiększenie salda drugiego. Zatwierdzenie tylko pierwszej zmiany doprowadziłoby do utraty spójności danych, dlatego obie instrukcje powinny należeć do jednej transakcji. Gdy aktualizacja drugiego rachunku się nie powiedzie, pierwsza zmiana musi zostać anulowana.

Kontrola zatwierdzenia i wycofania zmian

Typowy przebieg obejmuje rozpoczęcie transakcji, wykonanie instrukcji modyfikujących dane, sprawdzenie ich wyniku oraz zakończenie przez zatwierdzenie albo wycofanie. Zatwierdzenie jest określane jako commit. Po jego wykonaniu zmiany stają się trwałą częścią danych zgodnie z zasadami konkretnego silnika bazy. Wycofanie, czyli rollback, usuwa skutki operacji wykonanych od początku transakcji lub od wskazanego punktu zapisu.

Procedura powinna reagować na błędy w sposób jednoznaczny. Samo przechwycenie wyjątku i zapisanie komunikatu nie gwarantuje spójności, jeżeli wcześniej wykonane instrukcje pozostaną aktywne. W obsłudze błędów trzeba ustalić, czy transakcja nadal może zostać zatwierdzona, czy należy ją wycofać. W zależności od używanego systemu pomocne mogą być mechanizmy obsługi wyjątków, punkty zapisu oraz informacje o stanie bieżącej transakcji. Należy także uwzględnić sytuację, w której błąd wystąpił po częściowym wykonaniu procedury.

Blokady, izolacja i czas trwania transakcji

Transakcja wpływa nie tylko na trwałość zmian, lecz także na sposób współpracy równoległych operacji. Silnik bazy danych może zakładać blokady na zmienianych rekordach lub używać mechanizmów wersjonowania, aby ograniczyć ryzyko odczytania danych pośrednich. Poziom izolacji określa, jakie skutki równoległych transakcji są widoczne dla innych operacji. Zbyt niski poziom może dopuścić do odczytów niezatwierdzonych albo do niespójnych wyników, a zbyt wysoki może zwiększyć liczbę oczekujących operacji i konfliktów.

Nie należy utrzymywać transakcji dłużej, niż wymaga tego logiczna operacja. Otwarta transakcja może zatrzymywać blokady, zwiększać zużycie zasobów i opóźniać inne zapytania. Szczególne ryzyko występuje wtedy, gdy procedura podczas aktywnej transakcji wykonuje czynności niezwiązane bezpośrednio z bazą, na przykład oczekuje na dane z zewnętrznego systemu. Właściwy projekt ogranicza zakres transakcji do koniecznych odczytów i zmian, a czasochłonne operacje wykonuje poza nią, jeżeli nie narusza to wymagań spójności.

Weryfikacja poprawności procedury transakcyjnej

Sprawdzenie procedury powinno obejmować zarówno scenariusz prawidłowego zakończenia, jak i każdy istotny wariant błędu. Należy zweryfikować, czy commit zapisuje wszystkie wymagane zmiany, czy rollback usuwa także zmiany wykonane przed miejscem wystąpienia błędu oraz czy procedura nie pozostawia otwartej transakcji po zakończeniu pracy. Warto testować błędy walidacji danych, naruszenie ograniczenia klucza, brak oczekiwanego rekordu, konflikt blokad i przerwanie wykonania.

Podczas analizy trzeba rozróżnić błąd samej instrukcji od błędu całego procesu. Pojedyncze zapytanie może zwrócić poprawny wynik, a mimo to procedura może nie zachować spójności, jeśli kolejne zapytanie nie zostanie wykonane albo jeśli zatwierdzenie nastąpi w niewłaściwym miejscu. Istotne jest również ustalenie, kto zarządza transakcją: sama procedura, aplikacja wywołująca czy warstwa pośrednia. Mieszanie tych odpowiedzialności może prowadzić do nieoczekiwanych zagnieżdżeń, przedwczesnego zatwierdzenia albo wycofania zmian należących do szerszego procesu. Diagnostyka powinna obejmować logi błędów, kolejność instrukcji, czas trwania transakcji oraz stan danych przed i po wykonaniu procedury.