Transakcje automatyczne

Transakcje automatyczne to niejawne transakcje otaczające każde pojedyncze polecenie modyfikujące dane.

Na czym polegają transakcje automatyczne

Transakcje automatyczne, nazywane także transakcjami niejawnymi albo trybem autocommit, polegają na tym, że system zarządzania bazą danych samodzielnie rozpoczyna i kończy transakcję obejmującą pojedyncze polecenie modyfikujące dane. Dotyczy to w szczególności instrukcji INSERT, UPDATE i DELETE. Użytkownik lub aplikacja nie musi wtedy wysyłać osobno polecenia rozpoczęcia transakcji ani jawnego COMMIT. Po poprawnym wykonaniu instrukcji zmiana zostaje zatwierdzona, a w razie błędu system wycofuje operację zgodnie z możliwościami konkretnego silnika i rodzaju błędu.

W tym trybie pojedyncze polecenie stanowi granicę transakcji. Przykładowo instrukcja UPDATE zmieniająca wartości w wielu wierszach jest traktowana jako jedna operacja: wszystkie zmiany wykonane przez to polecenie powinny zostać zatwierdzone razem albo wycofane razem. Nie oznacza to jednak, że kilka kolejnych instrukcji wykonanych przez aplikację tworzy jedną wspólną transakcję. Jeżeli aplikacja uruchomi kolejno INSERT, UPDATE i DELETE w trybie automatycznego zatwierdzania, każda z tych instrukcji może zostać zatwierdzona niezależnie.

Granica zatwierdzenia a spójność danych

Najważniejszą cechą transakcji automatycznych jest wyraźna granica zatwierdzania. Po zakończeniu pojedynczego polecenia inne połączenia z bazą mogą odczytać zatwierdzone wyniki, zależnie od poziomu izolacji i zasad widoczności danych stosowanych przez dany silnik. Jeżeli następne polecenie aplikacji zakończy się błędem, nie cofnie ono automatycznie wcześniejszej instrukcji, która została już zatwierdzona. Z tego powodu autocommit dobrze pasuje do niezależnych operacji, ale może być niewystarczający dla procedury składającej się z kilku wzajemnie zależnych zmian.

Przykładem jest przeniesienie środków między dwoma rachunkami. Sama instrukcja zmniejszająca saldo jednego rachunku i sama instrukcja zwiększająca saldo drugiego rachunku nie powinny być traktowane jako dwa niezależne zatwierdzenia. Gdy pierwsza operacja zostanie zatwierdzona, a druga nie wykona się z powodu błędu, dane mogą przestać odzwierciedlać pełną operację biznesową. W takim przypadku aplikacja powinna użyć jawnej transakcji, wykonać oba polecenia, a następnie wydać COMMIT dopiero po pomyślnym zakończeniu całego zestawu. Przy błędzie powinna wykonać ROLLBACK.

Transakcja automatyczna nie zastępuje mechanizmów kontroli spójności. Klucze główne, klucze obce, ograniczenia UNIQUE, ograniczenia CHECK oraz wyzwalacze nadal mogą odrzucić polecenie. Jeżeli odrzucona zostanie instrukcja obejmująca wiele wierszy, zachowanie zależy od silnika, sterownika i rodzaju błędu, dlatego aplikacja nie powinna zakładać identycznego przebiegu w każdej bazie danych. Istotne jest sprawdzenie dokumentacji używanego silnika oraz sterownika połączenia.

Wpływ autocommit na wykonanie poleceń

Każde automatyczne zatwierdzenie może powodować dodatkową pracę związaną z zapisem informacji potrzebnych do odtworzenia i trwałego zatwierdzenia zmian. Przy dużej liczbie małych operacji, na przykład podczas importu tysięcy rekordów, zatwierdzanie po każdej instrukcji może zwiększyć liczbę operacji wejścia i wyjścia oraz wydłużyć wykonanie zadania. W takiej sytuacji często stosuje się większe, jawnie wyznaczone partie operacji, ale ich rozmiar musi uwzględniać dostępne zasoby, blokady i wymagania dotyczące spójności.

Zmiana trybu autocommit powinna być kontrolowana na poziomie połączenia z bazą. W sterownikach programistycznych występują różne nazwy ustawień, na przykład właściwość autocommit lub metoda commit, lecz ich dokładne działanie zależy od używanego języka, sterownika i silnika. Samo wyłączenie autocommit nie zawsze oznacza natychmiastowe rozpoczęcie transakcji; w części środowisk transakcja zaczyna się dopiero przy pierwszym poleceniu odczytu lub modyfikacji. Po zakończeniu pracy aplikacja powinna jednoznacznie wykonać COMMIT albo ROLLBACK i zwolnić połączenie.

Osobnej uwagi wymagają polecenia definicji danych, takie jak CREATE TABLE, ALTER TABLE i DROP TABLE. Ich zachowanie transakcyjne nie jest jednakowe we wszystkich silnikach baz danych. Niektóre systemy pozwalają objąć określone polecenia DDL transakcją, inne wykonują niejawny commit przed takim poleceniem lub po nim, a jeszcze inne ograniczają możliwość wycofania zmian. Dlatego pojęcia transakcji automatycznych nie należy rozszerzać bez sprawdzenia na wszystkie instrukcje SQL. Podczas diagnostyki trzeba ustalić konkretny silnik, jego wersję oraz konfigurację sterownika.

Sprawdzanie skutków transakcji automatycznych

W diagnostyce problemu należy najpierw ustalić, czy połączenie działa w trybie autocommit, gdzie ustawiany jest ten tryb oraz czy aplikacja nie zmienia go w trakcie pracy. Następnie warto prześledzić kolejność poleceń modyfikujących dane, momenty wystąpienia błędów i informacje o zatwierdzeniu lub wycofaniu zmian. Szczególne znaczenie ma rozróżnienie błędu samego polecenia od błędu późniejszej operacji. Jeżeli pierwsze polecenie zostało już zatwierdzone, późniejszy ROLLBACK nie cofnie tej wcześniejszej, zakończonej transakcji.

Do typowych objawów nieprawidłowego doboru granic transakcji należą częściowo wykonane operacje, brak powiązanego rekordu, rozbieżne salda oraz dane widoczne w bazie mimo przerwania procesu aplikacji. Sam fakt, że pojedyncze polecenia wykonują się poprawnie, nie dowodzi poprawności całego przepływu danych. Należy sprawdzić także obsługę wyjątków: po błędzie połączenie może pozostawać w otwartej transakcji albo w stanie wymagającym ROLLBACK, zależnie od używanego środowiska. Błędne ponowne użycie takiego połączenia może powodować kolejne nieprzewidziane modyfikacje.

Podczas naprawy komputera lub aplikacji korzystającej z bazy warto zabezpieczyć kopię danych i odtworzyć problem na środowisku testowym. Test powinien obejmować poprawne wykonanie polecenia, błąd walidacji, utratę połączenia oraz przerwanie procesu pomiędzy kolejnymi instrukcjami. Dopiero porównanie stanu danych przed i po każdym scenariuszu pozwala stwierdzić, czy automatyczne transakcje zapewniają oczekiwany poziom spójności, czy też potrzebna jest jawna transakcja obejmująca cały zestaw zależnych operacji.