Obsługa błędów w transakcji

Obsługa błędów w transakcji to konstrukcja TRY-CATCH połączona z ROLLBACK, zapobiegająca pozostawieniu niespójnych danych.

Rola transakcji w utrzymaniu spójności danych

Obsługa błędów w transakcji obejmuje taki sposób wykonywania operacji na bazie danych, aby nie pozostawić tylko częściowo zapisanych zmian. Transakcja jest logicznym zestawem operacji traktowanym jako jedna całość. Jeżeli wszystkie wymagane działania zakończą się poprawnie, aplikacja zatwierdza wynik instrukcją COMMIT. Jeżeli wystąpi błąd, następuje wycofanie zmian instrukcją ROLLBACK. Dzięki temu system nie zapisuje stanu pośredniego, w którym jedna tabela została zmieniona, a powiązana z nią tabela pozostała w poprzednim stanie.

Mechanizm ten realizuje przede wszystkim zasadę atomowości z modelu ACID. Atomowość oznacza, że transakcja kończy się albo pełnym zatwierdzeniem wszystkich objętych nią operacji, albo wycofaniem tych operacji. Pozostałe właściwości ACID również mają znaczenie: spójność wymaga zachowania reguł integralności, izolacja ogranicza wpływ równoległych transakcji na siebie, a trwałość oznacza zachowanie zatwierdzonych danych po zakończeniu operacji. Sam ROLLBACK nie naprawia błędnej logiki aplikacji, ale zapobiega utrwaleniu niepełnego rezultatu.

TRY-CATCH i decyzja o wycofaniu zmian

Konstrukcja TRY-CATCH służy do rozdzielenia normalnego przebiegu transakcji od obsługi wyjątku. W bloku TRY umieszcza się operacje, które powinny zostać wykonane w ramach jednej transakcji, na przykład sprawdzenie warunku, zapis rekordu oraz aktualizację powiązanej wartości. Po pomyślnym zakończeniu tych działań wykonywany jest COMMIT. Jeżeli silnik bazy danych lub aplikacja zgłosi błąd, sterowanie przechodzi do bloku CATCH, gdzie można wykonać ROLLBACK, zapisać informacje diagnostyczne i przekazać wyjątek wyżej.

Istotne jest, aby ROLLBACK obejmował właściwą transakcję. Kod obsługi błędu powinien uwzględniać sytuację, w której transakcja nie została rozpoczęta, została już zatwierdzona albo znajduje się w stanie niepozwalającym na dalsze instrukcje. W przeciwnym razie sam mechanizm naprawczy może wygenerować kolejny błąd lub ukryć pierwotną przyczynę problemu. Po wykonaniu wycofania wyjątek powinien pozostać możliwy do rozpoznania przez warstwę wywołującą, ponieważ samo przerwanie transakcji nie informuje jeszcze, dlaczego operacja się nie powiodła.

Zakres transakcji, blokady i błędy częściowe

Bezpieczeństwo obsługi zależy od prawidłowego określenia zakresu transakcji. Powinien on obejmować operacje, które muszą zachować wspólną spójność, ale nie powinien być niepotrzebnie przedłużany przez czynności niezwiązane z bazą danych. Długa transakcja może utrzymywać blokady na rekordach lub innych zasobach, zwiększać prawdopodobieństwo konfliktu z innymi operacjami i ograniczać przepustowość systemu. W praktyce warto wykonać walidację danych przed rozpoczęciem zapisu, a czynności zewnętrzne, takie jak oczekiwanie na odpowiedź innej usługi, ograniczać w obrębie transakcji.

Błąd może wystąpić zarówno podczas zapisu, jak i przy zatwierdzaniu transakcji. Przykładami są naruszenie klucza unikatowego, naruszenie klucza obcego, odrzucenie wartości przez ograniczenie, utrata połączenia z bazą, przekroczenie limitu czasu lub zakleszczenie. Zakleszczenie powstaje wtedy, gdy równoległe transakcje wzajemnie oczekują na zasoby zablokowane przez drugą stronę. Silnik zwykle wybiera jedną transakcję do przerwania, dlatego aplikacja może potrzebować ponowienia całej operacji, a nie tylko ostatniej instrukcji. Ponowienie powinno mieć ograniczoną liczbę prób i nie może prowadzić do podwójnego wykonania skutków ubocznych.

Testowanie i diagnozowanie nieudanych transakcji

Poprawność obsługi błędów sprawdza się przez testy obejmujące każdy etap transakcji. Należy zweryfikować przypadek pełnego sukcesu, błąd pierwszej operacji, błąd operacji po wcześniejszych zapisach oraz błąd występujący przy COMMIT. Po każdym przypadku trzeba sprawdzić stan wszystkich powiązanych danych, a nie tylko komunikat zwrócony przez aplikację. Jeżeli transakcja została wycofana, nie powinny pozostać rekordy utworzone wyłącznie przez jej wcześniejsze kroki. Warto także testować równoległe wykonanie operacji, przerwanie połączenia i przekroczenie czasu oczekiwania.

Log powinien zawierać informacje pozwalające odtworzyć przebieg zdarzenia: identyfikator operacji, moment rozpoczęcia i zakończenia, typ błędu oraz informację, czy wykonano COMMIT albo ROLLBACK. Nie należy jednak zastępować obsługi wyjątku samym zapisem do logu. Po wykryciu błędu aplikacja powinna zwolnić zasoby, zakończyć transakcję w znanym stanie i zwrócić kontrolowany rezultat. Przy diagnostyce laptopa lub komputera PC można analizować błędy aplikacji, konfigurację sterowników bazodanowych, utratę połączeń oraz działanie programu zapisującego dane. W przypadku lokalnego oprogramowania biurowego szczególnie ważne jest ustalenie, czy problem dotyczy samej bazy, warstwy komunikacji, czy kodu, który nieprawidłowo zarządza kolejnością COMMIT i ROLLBACK.