Transakcja jawna

Transakcja jawna wymaga ręcznego rozpoczęcia i zakończenia poleceniami BEGIN oraz COMMIT lub ROLLBACK.

Ręczne sterowanie przebiegiem transakcji

Transakcja jawna to rozpoczęty przez programistę, administratora lub użytkownika logiczny zestaw operacji wykonywanych w bazie danych. Jej granice nie są pozostawione wyłącznie mechanizmowi automatycznego zatwierdzania pojedynczych poleceń. Autor kodu wskazuje moment rozpoczęcia transakcji, wykonuje w jej ramach odpowiednie instrukcje, a następnie podejmuje decyzję o zatwierdzeniu albo wycofaniu zmian. W typowym zapisie SQL do rozpoczęcia używa się polecenia BEGIN, natomiast zakończenie następuje przez COMMIT lub ROLLBACK. Dokładna składnia może zależeć od używanego silnika bazy danych i jego trybu zgodności.

Po wykonaniu BEGIN kolejne operacje modyfikujące dane, takie jak INSERT, UPDATE i DELETE, należą do tej samej transakcji, dopóki nie zostanie ona zatwierdzona, wycofana albo przerwana przez silnik. COMMIT potwierdza wykonane zmiany i kończy bieżącą transakcję. ROLLBACK cofa zmiany objęte transakcją do stanu sprzed jej rozpoczęcia lub do ostatniego punktu zapisu, jeśli silnik obsługuje punkty zapisu. Samo otwarcie transakcji nie oznacza więc, że każda wykonana instrukcja od razu staje się trwała.

Dlaczego jedna granica obejmuje wiele operacji

Jawne transakcje są używane wtedy, gdy kilka operacji powinno zostać potraktowanych jako jeden spójny proces. Przykładem może być przeniesienie środków między dwoma rachunkami w aplikacji: zmniejszenie salda pierwszego rachunku i zwiększenie salda drugiego powinny zostać wykonane razem. Jeżeli pierwsza zmiana zakończy się powodzeniem, a druga nie, aplikacja może wykonać ROLLBACK, aby nie pozostawić danych w stanie częściowo zmodyfikowanym. W podobny sposób można obejmować jedną transakcją zapis rekordu głównego oraz powiązanych rekordów szczegółowych.

Takie działanie wiąże się z właściwościami transakcyjności określanymi skrótem ACID. Atomowość oznacza, że zestaw operacji jest traktowany jako całość: zostaje zatwierdzony albo wycofany. Spójność wymaga zachowania reguł integralności zdefiniowanych w bazie, na przykład ograniczeń klucza obcego lub unikalności. Izolacja określa, w jakim stopniu równolegle wykonywane transakcje widzą nawzajem swoje niezakończone zmiany. Trwałość oznacza, że po pomyślnym zatwierdzeniu dane powinny przetrwać awarię procesu, a w zakresie przewidzianym przez silnik także awarię systemu.

Transakcja jawna nie gwarantuje automatycznie poprawności logiki biznesowej. Jeżeli program zatwierdzi dane w niewłaściwym momencie albo pominie istotną operację, baza może zachować technicznie poprawny, lecz niezgodny z założeniami stan. Granice transakcji powinny obejmować operacje, które muszą być spójne względem siebie, ale nie powinny być niepotrzebnie rozciągane na długie czynności niezwiązane z bazą.

COMMIT, ROLLBACK i obsługa błędów

W praktycznym kodzie decyzja o zatwierdzeniu transakcji powinna zależeć od wyniku wszystkich wymaganych operacji. Schemat logiczny wygląda następująco: aplikacja otwiera transakcję, wykonuje zestaw poleceń, sprawdza błędy i dopiero wtedy wywołuje COMMIT. Jeśli wystąpi wyjątek, naruszenie ograniczenia, błąd połączenia albo niepoprawny wynik walidacji, wykonywany jest ROLLBACK. W kodzie korzystającym z bibliotek dostęp do bazy często realizuje się przez obiekt połączenia, który udostępnia metody odpowiadające zatwierdzeniu i wycofaniu, ale nazwy tych metod zależą od języka i sterownika.

Istotne jest rozróżnienie między zmianami zatwierdzonymi i niezatwierdzonymi. Zależnie od poziomu izolacji inne połączenie może nie widzieć zmian wykonanych w trwającej transakcji, może zobaczyć ich wersję albo może zostać zablokowane do czasu zakończenia operacji. Niezatwierdzona transakcja może również utrzymywać blokady na wierszach lub innych zasobach. Jeżeli pozostanie otwarta zbyt długo, może spowalniać inne zapytania, zwiększać zużycie pamięci i powodować zakleszczenia. Dlatego połączenie powinno zawsze zakończyć transakcję w przewidywalny sposób, także w ścieżce obsługi błędu.

Polecenie ROLLBACK nie zawsze cofa skutki działań wykonanych poza mechanizmem transakcyjnym. Zakres odwracania zależy między innymi od silnika, rodzaju tabel, ustawień autocommit oraz rodzaju wykonanej instrukcji. Niektóre operacje administracyjne mogą mieć odmienną semantykę niż zwykłe modyfikacje danych. Z tego powodu kod powinien korzystać z dokumentacji konkretnego silnika, a testy powinny sprawdzać zarówno wariant pomyślny, jak i przerwanie transakcji po każdej istotnej operacji.

Transakcja jawna w programie działającym na komputerze

Użytkownik zwykle nie wydaje poleceń BEGIN, COMMIT i ROLLBACK bezpośrednio. Granice transakcji są zazwyczaj obsługiwane przez aplikację, sterownik bazy danych albo warstwę dostępu do danych. Gdy program zapisuje ustawienia, importuje dokumenty lub aktualizuje kilka tabel, poprawnie zaprojektowana transakcja pozwala uniknąć sytuacji, w której część informacji została zapisana, a pozostała część nie. W razie przerwania programu przed zatwierdzeniem silnik może wycofać niezakończoną transakcję podczas zamykania połączenia lub odzyskiwania po awarii, jednak szczegóły zależą od konkretnego rozwiązania.

Podczas diagnozowania problemu z aplikacją warto ustalić, czy program korzysta z autocommit, czy otwiera transakcje jawnie, kiedy wykonuje zatwierdzenie oraz jak reaguje na wyjątki. Objawami błędnej obsługi mogą być dane widoczne tylko w jednym oknie programu, brak zmian po ponownym uruchomieniu, blokady utrzymujące się długo po zakończeniu operacji albo powtarzające się komunikaty o konflikcie transakcji. Sama obecność polecenia BEGIN nie wystarcza do oceny poprawności; trzeba prześledzić pełną ścieżkę od rozpoczęcia do COMMIT lub ROLLBACK.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, dlatego przy problemach z aplikacją można rozpocząć diagnostykę od sprawdzenia systemu, połączenia z urządzeniami oraz poprawnego działania programu klienckiego. W przypadku samej bazy danych konieczne jest dodatkowo ustalenie używanego silnika, konfiguracji połączenia i logiki aplikacji, ponieważ znaczenie transakcji jawnej wynika z połączenia tych elementów, a nie tylko z pojedynczego polecenia SQL.