Transakcje wieloetapowe

Transakcje wieloetapowe obejmują kilka powiązanych operacji zatwierdzanych lub wycofywanych jako jedna całość.

Jak działa transakcja obejmująca kilka operacji

Transakcja wieloetapowa to logicznie spójny zestaw operacji wykonywanych na danych. Poszczególne kroki mogą dotyczyć różnych tabel, plików, rekordów lub usług, ale z punktu widzenia aplikacji tworzą jeden proces. Przykładem w systemie lokalnym może być zapis zamówienia, zmniejszenie stanu magazynowego oraz utworzenie informacji o płatności. Jeżeli wszystkie czynności zakończą się poprawnie, transakcja zostaje zatwierdzona poleceniem COMMIT. Jeżeli którykolwiek etap wykryje błąd, aplikacja może wycofać zmiany poleceniem ROLLBACK.

Mechanizm ten pozwala uniknąć stanu częściowego, w którym wykonano tylko fragment procedury. Sama liczba etapów nie definiuje jeszcze sposobu realizacji transakcji. W jednej bazie danych wszystkie operacje mogą być objęte wspólną transakcją, natomiast przy komunikacji kilku niezależnych systemów konieczne są dodatkowe reguły koordynacji. Istotne jest również rozróżnienie między pojedynczą instrukcją SQL a procesem biznesowym składającym się z wielu instrukcji. Kilka zapytań uruchomionych kolejno nie będzie automatycznie jedną transakcją, jeśli połączenie z bazą albo kod aplikacji nie otworzy i nie zamknie jawnie odpowiedniego zakresu transakcyjnego.

Atomowość, spójność i kolejność zatwierdzania

Transakcje wieloetapowe opisuje się zwykle za pomocą właściwości ACID. Atomowość oznacza, że cały zakres jest zatwierdzony albo wycofany jako całość. Spójność wymaga, aby po zakończeniu transakcji dane spełniały reguły narzucone przez system, na przykład ograniczenia klucza obcego, unikalności lub wartości niedopuszczalnych. Izolacja określa, w jakim stopniu równolegle wykonywane transakcje widzą wzajemnie swoje niezatwierdzone zmiany. Trwałość oznacza zachowanie zatwierdzonych danych po awarii procesu lub ponownym uruchomieniu systemu.

W praktyce przebieg powinien mieć jasno określony punkt rozpoczęcia, listę operacji oraz warunek zatwierdzenia. Błąd techniczny, naruszenie ograniczenia danych albo negatywny wynik walidacji powinien prowadzić do jednoznacznej obsługi niepowodzenia. Należy też ustalić, które działania rzeczywiście należą do transakcji. Odczyt danych może wpływać na decyzję o zatwierdzeniu, ale samo wyświetlenie wyniku użytkownikowi zwykle nie jest operacją, którą da się cofnąć w bazie. Długie transakcje blokują zasoby przez dłuższy czas, dlatego zakres powinien być możliwie krótki i nie powinien obejmować oczekiwania na ręczną reakcję użytkownika.

Blokady, współbieżność i sytuacje awaryjne

Podczas wieloetapowej transakcji system zarządzania bazą danych może zakładać blokady na zmienianych rekordach lub zakresach danych. Ich celem jest ochrona przed równoczesnym zapisaniem sprzecznych wartości. Jeżeli dwie transakcje próbują zmienić te same dane, jedna z nich może czekać na zakończenie drugiej. Zbyt długie przetrzymywanie blokad zwiększa ryzyko opóźnień, przekroczenia limitu czasu oraz zakleszczenia. Zakleszczenie występuje wtedy, gdy transakcje wzajemnie oczekują na zasoby zablokowane przez drugą stronę. Baza danych zwykle wybiera jedną transakcję do przerwania, ale aplikacja musi poprawnie obsłużyć taki wynik.

Diagnostyka problemu wymaga sprawdzenia logów aplikacji, identyfikatora transakcji, kolejności wykonywania operacji oraz komunikatów silnika bazy danych. Warto ustalić, czy błąd nastąpił przed zatwierdzeniem, w trakcie wycofywania, czy po stronie mechanizmu komunikacji. Szczególnej uwagi wymagają ponowienia żądania po przekroczeniu limitu czasu. Ponowienie może być bezpieczne tylko wtedy, gdy operacje są idempotentne, czyli wielokrotne wykonanie tego samego żądania prowadzi do tego samego efektu logicznego. Przy operacjach zwiększających saldo, wysyłających płatność lub tworzących rekord bez unikalnego identyfikatora samo ponowienie może doprowadzić do podwójnego wykonania.

Transakcje rozproszone i diagnostyka niespójności

Gdy kolejne etapy obejmują różne bazy danych albo niezależne usługi, klasyczny COMMIT jednej bazy nie gwarantuje zatwierdzenia pozostałych. Jednym z formalnych mechanizmów jest protokół two-phase commit, czyli zatwierdzanie dwufazowe. W fazie przygotowania uczestnicy sprawdzają, czy mogą wykonać zapis i utrzymać wymagane zasoby. W fazie zatwierdzenia koordynator przekazuje decyzję o zakończeniu transakcji. Rozwiązanie to wymaga dostępnego koordynatora oraz może długo utrzymywać blokady, dlatego nie zawsze jest odpowiednie dla połączeń o dużych opóźnieniach lub systemów, które muszą działać niezależnie.

Alternatywą jest wzorzec sagi, w którym każdy etap ma własną lokalną transakcję, a niepowodzenie uruchamia operacje kompensujące wcześniejsze kroki. Kompensacja nie jest technicznym cofaniem danych w identycznym sensie jak ROLLBACK; jest nową operacją przywracającą uzgodniony stan, na przykład anulowanie rezerwacji po nieudanym pobraniu płatności. W diagnostyce należy porównać stan wszystkich uczestniczących komponentów, kolejność komunikatów i identyfikatory korelacyjne. W komputerze użytkownika można dodatkowo sprawdzić stabilność połączenia, działanie aplikacji klienckiej, dostępne miejsce na dysku oraz kompletność lokalnych logów. Jeżeli problem dotyczy uszkodzenia systemu, błędnej konfiguracji lub niestabilnej pracy komputera, Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów i komputerów PC oraz diagnostykę podzespołów związanych z działaniem oprogramowania.