Czas życia transakcji

Czas życia transakcji to okres, przez jaki operacja bazodanowa pozostaje otwarta przed zatwierdzeniem lub wycofaniem.

Jak rozumieć czas życia transakcji

Czas życia transakcji, określany także jako czas trwania transakcji, to przedział między rozpoczęciem logicznie wydzielonego zestawu operacji na danych a jego zakończeniem. Zakończenie następuje przez zatwierdzenie zmian, zwykle operacją COMMIT, albo przez ich wycofanie, czyli ROLLBACK. W tym okresie system bazodanowy traktuje wykonywane instrukcje jako jedną całość. Jeżeli transakcja zostanie zatwierdzona, jej zmiany stają się trwałe zgodnie z zasadami używanego silnika. Jeżeli zostanie wycofana, silnik przywraca stan sprzed rozpoczęcia transakcji w zakresie operacji objętych tym wycofaniem.

Nie należy utożsamiać czasu życia transakcji z czasem działania pojedynczego zapytania. Jedno zapytanie może wykonać się szybko, a po jego zakończeniu transakcja nadal pozostaje otwarta i oczekuje na kolejne operacje. Taki stan występuje między innymi wtedy, gdy aplikacja korzysta z ręcznego zarządzania transakcjami albo gdy połączenie z bazą pozostaje w trybie transakcyjnym. Czas życia obejmuje więc również przerwy między instrukcjami, oczekiwanie na dane wejściowe, oczekiwanie na blokady oraz opóźnienia wynikające z komunikacji między aplikacją a bazą.

Co dzieje się z blokadami i widocznością danych

Otwarta transakcja może wpływać na inne operacje wykonywane równocześnie. W zależności od silnika, poziomu izolacji i rodzaju instrukcji system może zakładać blokady na zmienianych lub odczytywanych rekordach, stronach danych albo innych strukturach. Blokada może uniemożliwić równoległą modyfikację tego samego fragmentu danych, opóźnić odczyt albo doprowadzić do oczekiwania na zakończenie innej transakcji. Im dłużej transakcja pozostaje aktywna, tym dłużej zasoby związane z jej pracą mogą być zajęte.

Czas trwania transakcji wpływa również na to, jaki obraz danych widzi aplikacja. Poziom izolacji określa, czy odczyt może zobaczyć zmiany zatwierdzone przez inne transakcje, czy odczyt pozostaje powtarzalny oraz czy system musi chronić określony zakres danych przed równoległą zmianą. W modelach wykorzystujących wersjonowanie rekordów długa transakcja może wymagać zachowania starszych wersji danych przez dłuższy czas. W modelach opartych głównie na blokadach może natomiast zwiększać liczbę oczekujących operacji. Konkretne zachowanie zależy od wybranego silnika bazy danych i jego konfiguracji, dlatego nie można przenosić szczegółowych reguł z jednego systemu do innego.

Przekroczenie określonego czasu nie zawsze oznacza automatyczne wycofanie transakcji. Limit może być ustawiony w aplikacji, sterowniku, puli połączeń, systemie operacyjnym albo konfiguracji konkretnego silnika, a każda z tych warstw może reagować inaczej. Jedna warstwa może przerwać oczekiwanie na blokadę, inna zamknąć połączenie, a jeszcze inna pozostawić transakcję w stanie wymagającym jawnego wycofania. Dlatego przy analizie problemu trzeba ustalić, która warstwa mierzy czas i jaki rodzaj limitu został przekroczony.

Krótka i długa transakcja w przepływie aplikacji

W poprawnie zaprojektowanym przepływie transakcja powinna obejmować operacje, które muszą zostać wykonane razem z punktu widzenia spójności danych. Typowy schemat polega na pobraniu potrzebnych informacji, sprawdzeniu warunków, zapisaniu powiązanych zmian i szybkim zatwierdzeniu wyniku. Poza transakcją powinny pozostawać czynności, które nie są konieczne do zachowania spójności, takie jak oczekiwanie na ręczną decyzję użytkownika, długie przetwarzanie pliku, komunikacja z odległą usługą albo wykonywanie czasochłonnych obliczeń.

Problem pojawia się wtedy, gdy aplikacja otwiera transakcję zbyt wcześnie i zamyka ją dopiero po zakończeniu wielu niezależnych etapów. W takim przypadku połączenie może być zajęte przez cały okres oczekiwania, a inne żądania mogą otrzymywać mniej dostępnych połączeń z puli. Długie transakcje utrudniają także rozpoznanie rzeczywistego miejsca awarii: błąd może wystąpić w późnej fazie, mimo że część zmian została wykonana znacznie wcześniej. Jeżeli kod nie obsłuży wyjątku przez ROLLBACK albo zamknięcie odpowiedniego kontekstu transakcyjnego, połączenie może zostać zwrócone do puli z nieoczekiwanym stanem.

Podczas diagnostyki warto porównać moment rozpoczęcia transakcji z czasem ostatniej instrukcji, czasem zatwierdzenia lub wycofania oraz czasem zwolnienia połączenia. Należy sprawdzić, czy transakcja obejmuje odczyty, które nie muszą być częścią zapisu, czy występują oczekiwania na blokady oraz czy błędy połączenia pozostawiają niezamknięte jednostki pracy. Pomocne są logi aplikacji zawierające identyfikator żądania, identyfikator połączenia i informację o wyniku transakcji. Sam komunikat o wolnym zapytaniu nie wystarcza, ponieważ opóźnienie może wynikać z oczekiwania na cudzą transakcję, a nie z kosztu wykonania własnej instrukcji.

Znaczenie czasu transakcji przy awarii komputera

Na laptopie lub komputerze PC objawy związane z długimi transakcjami mogą przypominać problem sprzętowy albo ogólne spowolnienie programu. Aplikacja korzystająca z bazy może długo wyświetlać komunikat oczekiwania, przestać reagować na kolejne polecenia albo zgłaszać błąd połączenia. Przyczyną nie musi być uszkodzony dysk lub pamięć operacyjna. Możliwe jest także wyczerpanie puli połączeń, blokada danych, przerwana sesja albo nieprawidłowo obsłużony wyjątek w kodzie. Rozróżnienie tych przyczyn wymaga sprawdzenia logów, stanu aplikacji, parametrów połączenia i zachowania komputera podczas wystąpienia problemu.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów stacjonarnych PC i ich podzespołów, dlatego przy problemach z działaniem programu na komputerze można rozpocząć od sprawdzenia warstwy sprzętowej oraz lokalnego środowiska pracy. W przypadku objawów wskazujących na czas życia transakcji istotne jest zachowanie dokładnego komunikatu błędu i informacji o tym, co aplikacja wykonywała przed zawieszeniem. Pozwala to oddzielić awarię komputera, systemu operacyjnego lub nośnika danych od problemu z logiką aplikacji, połączeniem z bazą albo obsługą otwartej transakcji.