Wyzwalacz a transakcje

Wyzwalacz działa w kontekście transakcji operacji, która go uruchomiła, i może spowodować jej wycofanie.

Jak wyzwalacz uczestniczy w transakcji

Wyzwalacz, nazywany także triggerem, to fragment kodu przypisany do określonego zdarzenia w bazie danych. Zdarzeniem może być między innymi dodanie rekordu, zmiana istniejącego rekordu albo jego usunięcie. Wyzwalacz uruchamia się automatycznie w reakcji na operację wykonaną przez aplikację lub użytkownika. Jeżeli operacja jest częścią transakcji, wyzwalacz zwykle wykonuje się w ramach tego samego kontekstu transakcyjnego. Oznacza to, że zmiany wprowadzone przez wyzwalacz są traktowane jako element większego zestawu zmian, a nie jako niezależna czynność.

Transakcja służy do przeprowadzenia powiązanych operacji jako jednej logicznej całości. Typowe właściwości transakcji opisuje się pojęciem ACID: atomowość oznacza wykonanie całości albo anulowanie całości, spójność wymaga zachowania reguł bazy, izolacja ogranicza wpływ równoległych operacji, a trwałość zapewnia zachowanie zatwierdzonych zmian. Wyzwalacz może uczestniczyć w realizacji tych zasad, na przykład automatycznie uzupełniać tabelę historii po zmianie danych albo odrzucać operację naruszającą warunek integralności.

Zatwierdzenie, wycofanie i błąd w kodzie triggera

Jeżeli wyzwalacz zakończy się poprawnie, jego instrukcje pozostają częścią bieżącej transakcji i zostają zatwierdzone razem z operacją, która go uruchomiła. Przykładowo, aplikacja może zmienić status zlecenia, a wyzwalacz może dopisać wpis do tabeli audytowej. Zatwierdzenie transakcji obejmuje wtedy zarówno zmianę statusu, jak i wpis historyczny. Jeżeli transakcja zostanie wycofana przed zatwierdzeniem, cofnięciu podlegają także zmiany wykonane przez wyzwalacz, o ile konkretny silnik nie stosuje dla danej operacji odrębnych zasad.

Błąd wykryty podczas działania wyzwalacza może przerwać operację wywołującą. Przyczyną może być naruszenie ograniczenia integralności, próba wpisania wartości niezgodnej z typem kolumny, błąd składni albo jawne zgłoszenie błędu przez kod triggera. W takim przypadku transakcja może zostać oznaczona jako nieudana i wymagać wycofania. Zakres reakcji zależy od silnika bazy danych oraz rodzaju błędu: nie każdy system obsługuje błędy i zagnieżdżone transakcje identycznie, dlatego zachowania nie należy uogólniać między PostgreSQL, SQL Server, MySQL i Oracle.

Wyzwalacz nie powinien samowolnie zatwierdzać niezależnej części operacji, ponieważ mogłoby to naruszyć atomowość transakcji. W wielu silnikach instrukcja zatwierdzenia lub wycofania w triggerze jest niedozwolona albo ma ograniczone zastosowanie. Projektant powinien sprawdzić dokumentację używanego produktu, zwłaszcza gdy wyzwalacz wykonuje dodatkowe zapisy, wywołuje funkcje albo działa podczas masowej modyfikacji wielu wierszy.

Spójność danych a kolejność wykonywania operacji

Najczęstszym zastosowaniem wyzwalacza w transakcji jest automatyczne utrzymanie zależności między tabelami. Po zmianie rekordu może on zaktualizować licznik, utworzyć wpis historii, sprawdzić zakres wartości albo dopilnować powiązania z inną tabelą. Dzięki temu reguła jest wykonywana niezależnie od tego, czy dane zmienia aplikacja internetowa, program lokalny czy bezpośrednie polecenie administracyjne. Trzeba jednak pamiętać, że wyzwalacz działa w określonym momencie, na przykład przed operacją albo po niej, a dokładne możliwości zależą od konkretnego silnika.

Znaczenie ma również zakres działania. Niektóre wyzwalacze są wykonywane dla każdego zmienianego wiersza, a inne raz dla całej instrukcji. Przy operacji aktualizującej tysiące rekordów różnica ta wpływa na sposób pisania kodu i na obciążenie systemu. Trigger zaprojektowany z założeniem, że zawsze zmienia się jeden rekord, może błędnie obsłużyć aktualizację zbiorczą. Może także wielokrotnie wykonywać kosztowne zapytania, wydłużając transakcję i zwiększając czas blokowania danych.

Wyzwalacze mogą tworzyć zależności pośrednie, które utrudniają analizę awarii. Jedna instrukcja aplikacji może uruchomić trigger, ten może zmienić kolejną tabelę, a następnie uruchomić następny wyzwalacz. W rezultacie błąd zgłoszony przez aplikację nie zawsze wskazuje miejsce, w którym rozpoczął się problem. Podczas diagnozy należy ustalić pierwotną operację, kolejność wywołań, liczbę zmienionych rekordów oraz to, czy transakcja została zatwierdzona, czy wycofana.

Rozpoznawanie problemów w aplikacji korzystającej z bazy

Objawem nieprawidłowego działania wyzwalacza może być pozornie losowe odrzucanie formularza, brak zapisu zmian, niespójny wpis w tabeli pomocniczej albo komunikat o blokadzie. Sama obecność rekordu w jednej tabeli nie dowodzi, że cała transakcja zakończyła się sukcesem. W przypadku wycofania transakcji zapis wykonany przez aplikację i zapis wykonany przez trigger mogą zniknąć jednocześnie. Diagnostyka wymaga więc sprawdzenia logu aplikacji, komunikatu silnika bazy, definicji wyzwalacza i granic transakcji w kodzie programu.

Przy pracy na laptopie lub komputerze PC warto rozdzielić problemy logiczne od problemów środowiskowych. Błąd triggera może wyglądać podobnie do zerwanego połączenia, nieprawidłowych uprawnień, pełnego dysku albo niedostępnej usługi bazy. Pomocne jest porównanie czasu błędu w logach, sprawdzenie, czy inne operacje zapisują dane poprawnie, oraz wykonanie kontrolnej operacji na kopii testowej. Nie należy wyłączać wyzwalacza na działającym systemie bez oceny skutków, ponieważ może to pozwolić na zapis danych z pominięciem wymaganych reguł.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, a przy diagnozie aplikacji może pomóc oddzielić awarię sprzętu, systemu operacyjnego lub połączenia od błędu logiki transakcji w używanym oprogramowaniu.