070 TRANSAKCJE Prof. dr hab. Marek Wisła
Transakcja - definicja Transakcja jest sekwencją logicznie powiązanych operacji na bazie danych, przeprowadzających bazę danych z jednego stanu spójnego w inny stan spójny.
Przykład Transakcja jest podstawową logiczną jednostką interakcji użytkownika z systemem bazy danych, jest to określona sekwencja operacji, która musi zakończyć się sukcesem w całości (baza pozostaje spójna) w przeciwnym przypadku (zagrożenie utraty spójności) przywrócony musi być stan początkowy. Przykład Operacja przelewu kwoty X z konta A na konto B: 1. Pobranie kwoty X z konta A 2. Dodanie kwoty X do konta B Transakcja jest logiczną jednostką działań, której nie można podzielić.
Transakcje Transakcja jest dowolną sekwencją operacji zdefiniowanych przez użytkownika i z jego punktu widzenia niepodzielną. Jeżeli choć jedna z operacji zawartej w transakcji nie może zostać wykonana, to wszystkie operacje z transakcji są wycofywane. Użytkownik oczekuje, że: efekt wykonania transakcji będzie niezależny od transakcji innych użytkowników i ich liczby, efekt wykonania transakcji będzie stanem poprawnym. Dowolna transakcja w bazie danych powinna być odizolowana od wszystkich pozostałych transakcji, które są wykonywane w tym samym czasie - w idealnej sytuacji, każda transakcja zachowuje się tak, jakby posiadała wyłączny dostęp do bazy danych.
Własności ACID transakcji Atomowość (Atomicity) - każda transakcja stanowi pojedynczą, niepodzielną jednostkę przetwarzania (a także odtwarzania) - w transakcji nie ma więc podtransakcji. Spójność (Consistency) - transakcja rozpoczyna się w spójnym stanie bazy danych i pozostawia bazę danych w stanie spójnym (tym samym lub innym). Odizolowanie (Isolation) - zmiany wykonywane przez transakcję nie zatwierdzoną, nie są widziane przez inne transakcje (chyba, że przyjęty poziom izolacji na to zezwala). Trwałość (Durability) - zmiany w bazie danych dokonane przez transakcję zatwierdzoną są na trwale zapisane w bazie danych.
A(tomicicity)CID Atomowość oznacza, że transakcję musimy traktować jako niepodzielną całość. Nie można więc przyjąć, że na przykład system utrwala wykonanie w bazie danych dwóch pierwszych operacji zakładając, że po jakimś czasie zrealizuje dwie następne operacje - byłaby to koncepcja wyróżniania podtransakcji, co w tradycyjnych systemach baz danych jest niedopuszczalne. Jeśli z jakiegoś powodu wykonanie transakcji ulegnie przerwaniu (na przykład w wyniku awarii) po dwóch pierwszych operacjach, to system musi zapewnić wycofanie wszystkich dokonanych zmian.
AC(onsistency)ID Spójność oznacza, że system nie dopuści do zatwierdzenia transakcji, która naruszy jakikolwiek warunek spójności bazy danych. W przykładzie przelewu kwoty między rachunkami bankowymi warunkiem spójności może być wymaganie, aby stan rachunku bankowego był zawsze większy od zera (statyczny warunek spójności) lub aby suma stanów kont po wykonaniu transakcji przelewu była taka sama jak przed jej wykonaniem (dynamiczny warunek spójności, tzn. odwołujący się do kilku różnych stanów bazy danych).
ACI(solation)D Odizolowanie oznacza, że zmiany wykonane przez jedną transakcję nie są widoczne dla innych transakcji dopóty, dopóki transakcja ta nie zostanie zatwierdzona. Postulat odizolowania transakcji jest najczęściej osłabiany przez jawne określanie poziomu izolacji - celem obniżenia poziomu izolacji jest zwiększenie współbieżności transakcji, wiąże się to jednak z ryzykiem powstawania pewnych anomalii.
ACID(urability) Trwałość oznacza, że zmiany wprowadzone do bazy danych przez transakcję, która została zatwierdzona, są w tej bazie danych zapisane na trwałe. Zmiany wykonywane przez transakcję muszą być zapisywane w osobnej lokalizacji (log) tak, aby można było szybko zatwierdzić zmiany lub je wycofać. Oznacza to, że również w przypadku różnorodnych awarii (z wyłączeniem fizycznego zniszczenia nośnika danych) musi istnieć mechanizm ich odtwarzania. Automatycznie jest wówczas odtwarzany ostatni poprawny (spójny) stan bazy danych, a więc zmiany wprowadzone w trakcie transakcji zostaną wówczas wycofane.
Transakcje proste Dowolne polecenie SELECT, INSERT, UPDATE, DELETE, CREATE rozpoczyna transakcję, o ile nie była ona już rozpoczęta. Jeśli polecenie SELECT, INSERT, UPDATE, DELETE, CREATE rozpoczyna transakcję, to transakcja jest automatycznie kończona natychmiast po wykonaniu tego polecenia..
Transakcje złożone Polecenie BEGIN TRANSACTION (lub BEGIN TRAN) rozpoczyna transakcję. Polecenie COMMIT [TRANSACTION TRAN] informuje, że wszystkie elementy transakcji są kompletne i powinny zostać zatwierdzone na stałe oraz stać się dostępne dla wszystkich innych transakcji. Polecenie ROLLBACK [TRANSACTION TRAN] mówi, że należy wycofać transakcję, a wszystkie zmiany danych dokonane przez transakcję mają być anulowane. Baza danych, z punktu widzenia użytkowników, powinna się znajdować w takim stanie, jak w momencie rozpoczęcia transakcji.
Współbieżność W systemie, w którym istnieje wiele stanowisk komputerowych może być tworzonych bardzo wiele transakcji, z których duża liczba może być wykonywana jednocześnie. Współbieżność transakcji oznacza, że przed zakończeniem jednej transakcji rozpoczynana jest następna (inicjowana na przykład z innego stanowiska komputerowego). Współbieżne wykonywanie operacji oznacza wykonywanie operacji pochodzących z różnych transakcji w czasie, gdy transakcje te są aktywne. Transakcje, których operacje wykonywane są współbieżnie, nazywamy transakcjami współbieżnymi. Współbieżność może prowadzić do rywalizacji o dane i konfliktów.
Konflikty Operacje o[a] na zbiorze danych A oraz p[b] na zbiorze danych B nie są konfliktowe, jeśli zachodzi co najmniej jeden z poniższych warunków: operacje o A, p[b] pochodzą z tej samej transakcji, A B = tzn. operacje dotyczą rozłącznych zbiorów danych, żadna z operacji nie jest operacją zapisu, jedna z operacji pochodzi z transakcji, która w chwili wykonywania drugiej została już zakończona (zatwierdzona lub odrzucona).
Anomalia zagubionej aktualizacji (Lost update) Trans T Trans S Opis begin T begin S write T [x: 10] Zapisz wartość x = 10 write S [x: 5] Zapisz wartość x = 5 commit T commit S Zatwierdzenie transakcji T Zatwierdzenie transakcji S Jaka wartość x jest prawidłowa: 5 czy 10???
Anomalia zagubionej aktualizacji Anomalia zagubionej aktualizacji występuje wtedy, gdy dwie transakcje wykonują zapis na tym samym zbiorze danych. W celu uniknięcia tej anomalii serwer SQL zawsze traktuje dwie transakcje dokonujące zapisu na tym samym zbiorze danych jako konfliktowe na wszystkich poziomach izolacji transakcji (od poziomu 0 do 3).
Anomalia nieodtwarzalności bazy danych Trans T Trans S Opis begin T begin S Początkowa wartość danej x = 1 Rozpoczęcie transakcji T Rozpoczęcie transakcji S write T [x: 2] Zapis wartości danej x (= 2) read S [x] Wczytanie wartości danej x (=1) write S [x: 5] Zapis nowej wartości danej x (=5) commit S Zatwierdzenie transakcji S rollback T Wycofanie transakcji T: x = 1 czy 5??? Należy wycofać wszystkie zmiany, jakie wprowadziła w bazie danych transakcja T, a także wszystkie konsekwencje tych zmian, w szczególności więc zmianę wartości danej x na 1. Ta ostatnia operacja jest jednak niemożliwa, gdyż transakcja S wykonła zmianę wartości x na 5 i ta zmiana jest już zatwierdzona. Zaistniała sytuacja, w której baza danych jest nieodtwarzalna
Czytanie z transakcji Definicja: Mówimy, że transakcja S czyta z transakcji T daną x, jeśli T nie została jeszcze zatwierdzona, T zapisała wartość x zanim transakcja S odczytała wartość x, Mamy więc do czynienia z sekwencją operacji: write T [x, ], read S [x]. Powodem wystąpienia anomalii nieodtwarzalności jest to, że transakcja S czytała i wykorzystywała dane przed zatwierdzeniem transakcji T (tzw. dirty read) i sama została zatwierdzona przed zatwierdzeniem T. Aby sytuacji takiej uniknąć, należałoby czekać z atwierdzeniem transakcji S do czasu, aż zostanie zatwierdzona transakcja T.
Zasada odtwarzalności Przetwarzanie (grupy) transakcji jest przetwarzaniem odtwarzalnym, jeśli każda transakcja jest zatwierdzana dopiero po zatwierdzeniu wszystkich transakcji, z których ona czyta.
Anomalia powtórnego czytania Trans T begin T Trans S begin S Początkowa wartość x = 1 read T [x] transakcja T przeczytała daną x (=1) write S [x: 5] Zapis nowej wartości x (= 5) read T [x] commit S Zatwierdzenie transakcji S Ponowny odczyt danej x. Jaka powinna być jej wartość 1 czy 5??? Jeśli transakcja T ponownie przeczyta daną x, to może się okazać, że dana ta ma inną wartość (zabronione jest czytanie z niezatwierdzonych transakcji, możliwe jest natomiast zapisywanie w niezatwierdzonych transakcjach). Transakcja T dysponuje więc dwiema różnymi wartościami tej samej danej. Może zdarzyć się też sytuacja, że transakcja S usunie daną x. Wówczas przy próbie ponownego czytania, transakcja T ma informację, że danej x nie ma w bazie danych. Opisaną anomalię nazywamy anomalią powtórnego czytania.
Zapis w transakcji Definicja: Mówimy, że transakcja S zapisuje w transakcji T daną x, jeśli T jest transakcją aktywną, T odczytała wartość x zanim ta wartość została zmieniona przez S. Mamy więc do czynienia z sekwencją operacji: read T [x], write S [x, ]. Powodem występowania anomalii powtórnego czytania jest to, że dopuszczalne jest zapisywanie w niezatwierdzonych transakcjach. Anomalię tę można wyeliminować zakładając, że zapisywanie danych wczytanych przez inną transakcję jest dopuszczalne dopiero wtedy, gdy transakcja ta została już zatwierdzona.
Zasada zapobiegania anomalii powtórnego czytania Przetwarzanie (grupy) transakcji jest przetwarzaniem bez anomalii powtórnego czytania (tj. z powtarzalnym czytaniem Repeatable Read), jeśli żadna z transakcji wchodząca w jej skład nie zapisuje w transakcjach niezatwierdzonych.
Anomalia przetwarzania z fantomami Trans T Trans S Opis begin T select where φ select where φ begin S insert where φ commit_s Wczytanie rekordów spełniających warunek φ (np. ilość zwróconych rekordów: 10) Wstawienie 2 nowych rekordów spełniających warunek φ Zatwierdzenie transakcji S Ponowne wczytanie rekordów spełniających warunek φ. Ile rekordów zostanie zwróconych 10 czy 12??? Podobna sytuacja wystąpi, jeśli transakcja S dokona takiej modyfikacji rekordu r nie spełniającego warunku φ, że po jej wykonaniu rekord r warunek ten będzie spełniał. Ten nowy rekord pojawiający się w obszarze zainteresowań transakcji T nazywany jest fantomem lub zjawą
Anomalia przetwarzania z fantomami Powodem pojawienia się fantomów jest to, że dopuszczalna jest zmiana zbioru danych, na którym operuje transakcja T. Konflikt między T i S nie jest więc bezpośredni, jak miało to miejsce przy anomalii powtórnego czytania. Pojawianiu się fantomów można zapobiec zakładając, że zmiany wykonywane przez transakcję S (wstawianie, usuwanie, aktualizacja) są takie, że nie powodują zmiany zbioru danych, na których operuje transakcja T.
Zasada zapobiegania pojawianiu się fantomów Przetwarzanie (grupy) transakcji jest przetwarzaniem bez fantomów, jeśli żadna z transakcji wchodzących w jego skład nie zmienia zbioru danych, na którym działa jakakolwiek inna transakcja niezatwierdzona.
Poziomy izolacji Wyróżniamy cztery poziomy izolacji transakcji: najniższy (0) - zapewnia największą współbieżność, wiąże się z największym ryzykiem (mogą wystąpić anomalie), najwyższy (3) - pozwala uniknąć wszelkich anomalii, ale jest najbardziej kosztowny (często ponoszenie tych kosztów jest niepotrzebne). Przyjęcie konkretnego poziomu izolacji wiąże się z określonymi problemami: - niski poziom zapewni nam zwiększenie współczynnika współbieżności, ale może doprowadzić do niekorzystnych cech związanych z zachowaniem spójności bazy danych. Poziom wysoki to dłuższy czas wykonywania transakcji, ale jednocześnie większa niezawodność przetwarzania oraz jego bezpieczeństwo z punktu widzenia zachowania spójności bazy danych.
Poziom izolacji 0 Poziom izolacji 0 dopuszcza czytanie przez transakcję danych niezatwierdzonych (uncommitted), tj. danych, które zostały zmienione przez transakcję jeszcze niezatwierdzoną. Za operacje konfliktowe uważa się tylko parę operacji zapisu, a dwie operacje, z których jedna jest operacją odczytu nie są operacjami konfliktowymi. W standardzie SQL2 (także w MS SQL Server) ten poziom izolacji nazywany jest także READ UNCOMMITTED, a popularnie określany jest jako dirty read ( brudne czytanie ).
Poziom izolacji 0 Przyjęcie tego rodzaju współbieżności operacji może doprowadzić do braku odtwarzalności, anomalii powtórnego czytania oraz do pojawiania się fantomów. Zaletą tego poziomu izolacji jest to, że uzyskujemy wysoki współczynnik współbieżność transakcji. Poziom izolacji 0 należy wybierać dla tych transakcji, które nie wykorzystają wczytanych danych do modyfikacji bazy danych.
Poziom izolacji 1 Poziom izolacji 1 wprowadza zakaz czytania danych z transakcji niezatwierdzonych, czytać można tylko dane zatwierdzone (committed). Za konfliktowe uważa się takie pary operacji, gdzie pierwsza jest operacją zapisu, a druga czytania lub obydwie są operacjami zapisu. Dwie operacje, z których pierwsza jest operacją czytania, a druga jest operacją zapisu, nie są więc konfliktowe. Poziom ten w standardzie SQL2 określany jest jako READ COMMITTED.
Poziom izolacji 1 Jest to domyślny poziom izolacji w MS SQL Server. Przy tym poziomie izolacji dopuszczalne jest jednak zapisywanie danych w transakcjach niezatwierdzonych. Przyjęcie tego rodzaju współbieżności operacji eliminuje brak odtwarzalności. Na tym poziomie izolacji może jednak wystąpić zarówno anomalia powtórnego czytania, jak i zjawisko fantomów.
Poziom izolacji 2 Poziom izolacji 2 wprowadza zakaz zapisywania w transakcjach niezatwierdzonych. Jeśli transakcja niezatwierdzona przeczytała jakąś daną, to dana ta może być tylko czytana przez inną transakcję. Jeśli natomiast transakcja niezatwierdzona zapisała jakąś daną, to nie można jej ani odczytać ani tym bardziej zapisać dopóty, dopóki transakcja ta nie zostanie zatwierdzona. Za konfliktowe uważa się takie pary operacji, gdzie pierwsza jest operacją zapisu lub druga jest operacją aktualizacji lub usuwania. W standardzie SQL2 ten poziom izolacji określa się jako REPEATABLE READ.
Poziom izolacji 2 Przyjęcie tego rodzaju współbieżności operacji eliminuje brak odtwarzalności oraz anomalię powtórnego czytania. Na tym poziomie izolacji mogą pojawiać się fantomy. Mamy zagwarantowane, że przy ponownym odwołaniu się do tych samych danych dostajemy identyczne informacje. Uzyskuje się to przez uniemożliwienie aktualizowania danych wczytanych przez transakcję, która nie została jeszcze zakończona. Przy tym poziomie izolacji współbieżność transakcji jest mniejsza niż przy READ COMMITTED. Należy więc stosować go tylko wtedy, gdy jest to naprawdę konieczne.
Poziom izolacji 3 Poziom izolacji 3 rozwiązuje problem fantomów. Za niekonfliktowe uważa się takie operacje, gdy działanie jednej z nich nie powoduje zmiany zbioru danych, na których działa druga. Ten poziom izolacji, nazywany SERIALIZABLE oznacza, że transakcje są szeregowalne (tj. wszystkie operacje jednej transakcji poprzedzają wszystkie operacje innej transakcji).
Poziom izolacji 3 Przyjęcie tego rodzaju współbieżności operacji eliminuje wszystkie anomalie, w tym problem fantomów. Przy tym poziomie izolacji współbieżność transakcji jest najmniejsza, a efektywność przetwarzania bardzo niska. Należy więc stosować go tylko wtedy, gdy jest to naprawdę konieczne.
Poziomy izolacji - podsumowanie Związek poziomów izolacji z anomaliami przetwarzania transakcji Poziom izolacji Zagubiony Update Brak odtwarzalności Anomalia powtórnego czytania Fantomy 0: READ UNCOMMITTED Nie Tak Tak Tak 1: READ COMMITTED Nie Nie Tak Tak 2: REPEATABLE READ Nie Nie Nie Tak 3: SERIALIZABLE Nie Nie Nie Nie
Operacje niekonfliktowe - podsumowanie Sekwencja transakcji (operujących na tym samym zbiorze danych): begin T - pierwsza transakcja begin S - druga transakcja Jakakolwiek operacja obejmuje odczyt, wstawianie, aktualizację i usuwanie. Poziom izolacji Trans T Trans S 0: READ UNCOMMITTED Odczyt Jakakolwiek operacja Jakakolwiek operacja Odczyt 1: READ COMMITTED Odczyt Jakakolwiek operacja 2: REPEATABLE READ Odczyt Odczyt Odczyt Wstawianie 3: SERIALIZABLE Odczyt Odczyt
Operacje konfliktowe - podsumowanie Sekwencja transakcji (operujących na tym samym zbiorze danych): begin T - pierwsza transakcja begin S - druga transakcja Zapis obejmuje trzy operacje: wstawianie, aktualizację i usuwanie. Jakakolwiek operacja obejmuje odczyt i zapis. Poziom Trans T Trans S 0: READ UNCOMMITTED Zapis Zapis 1: READ COMMITTED Zapis Jakakolwiek operacja 2: REPEATABLE READ Zapis Odczyt Odczyt 3: SERIALIZABLE Zapis Jakakolwiek operacja Jakakolwiek operacja Aktualizacja Usuwanie Jakakolwiek operacja Zapis
Zarządzanie współbieżnością Współbieżne wykonywanie transakcji może być przyczyną niespójności bazy danych (spowodowaną anomaliami). Rozwiązaniem są protokoły (algorytmy) zarządzania współbieżnością transakcji, które tak szeregują (porządkują) operacje wchodzące w skład współbieżnie wykonywanych transakcji, aby nie zachodziły anomalie.
Zarządzanie współbieżnością - algorytmy Problem poprawnego uporządkowania operacji współbieżnie wykonywanych transakcji jest rozwiązywany za pomocą następujących metod: algorytmy blokowania dostępu do danych - uszeregowanie transakcji wynika z kolejności uzyskiwania blokad, algorytmy znaczników czasowych - uszeregowanie transakcji wynika z wartości znaczników czasowych związanych z transakcjami i danymi, algorytmy optymistyczne - walidacja poprawności uszeregowania.
Planista Zarządzaniem transakcjami zajmuje się wyspecjalizowany moduł planisty. Zadaniem planisty jest tworzenie poprawnego planu przetwarzania transakcji. Planista przyjmując daną operację ma do dyspozycji następujące działania: przekazanie tej operacji do wykonania menedżerowi danych, umieszczenie operacji w kolejce, jeśli znajduje się ona w konflikcie z inną operacją i należy poczekać na zakończenie tejże operacji, odrzucenie operacji i tym samym całej transakcji, jeśli na przykład jest to konieczne z punktu widzenia rozwiązywania problemu zakleszczenia.
Blokowanie dostępu do danych Z każdą daną x związana jest blokada (lock). Wyróżniamy dwa podstawowe typy blokad: blokada współdzielona S (shared lock) - może być założona na daną x przez kilka transakcji jednocześnie; używana jest do blokowania danych do odczytu blokada wyłączna X (exclusive lock) - może być założona tylko przez jedną transakcję jednocześnie; zakładana jest na dane do zapisu Jedynie blokady typu S mogą być jednocześnie założone przez dwie różne transakcje. Nie jest możliwe łączenie blokad X i X oraz S i X.
Algorytm blokowania dwufazowego W komercyjnych SZBD najczęściej realizowanym algorytmem blokowania dostępu do danych jest tzw. algorytm blokowania dwufazowego (two-phase locking, 2PL). Wykonywanie każdej transakcji przebiega w dwóch fazach: faza blokowania (ekspansji): w tej fazie transakcja musi założyć wszystkie blokady do wszystkich danych, do których będzie chciała mieć dostęp; moment założenia wszystkich blokad, równoznaczny z zakończeniem fazy blokowania, jest nazywany punktem akceptacji (commit point), faza odblokowywania (zwijania): w tej fazie następuje zdejmowanie wszystkich nałożonych blokad, nie można już w tym momencie zakładać żadnych nowych blokad.
Algorytm blokowania dwufazowego Zaletą algorytmu 2PL jest to, że każdy utworzony przez niego plan przetwarzania transakcji jest poprawny. Wadą algorytmu 2PL jest to, że może prowadzić do powstania zakleszczeń (deadlock).
Algorytm 2PL zakładanie blokad Realizacja: blokadę S (SHARED) dla tej samej danej może założyć dowolna liczba transakcji, blokadę X (EXCLUSIVE) dla konkretnej danej może założyć tylko jedna transakcja, S i X nie mogą być jednocześnie założone na tę samą daną dla dwóch różnych transakcji, założenie blokady S jest konieczne dla odczytania danej, założenie blokady X jest konieczne dla zapisania (modyfikacji, usunięcia) danej.
Algorytm 2PL zdejmowanie blokad Sposób zdejmowania blokad związany jest z realizacją przetwarzania odpowiadającego różnym poziomom izolacji. Poziom izolacji 0: dana zablokowana na czas realizacji operacji read (blokada S) jest natychmiast odblokowywana po zakończeniu tej operacji dana zablokowana na czas realizacji operacji write (blokada X) po wykonaniu operacji write zmienia typ blokady na S, to znaczy może na niej być realizowana operacja read, ale nie operacja write, blokada dla operacji write zdejmowana jest całkowicie dopiero po zatwierdzeniu transakcji
Algorytm 2PL zdejmowanie blokad C blokada jest utrzymywana aż do zatwierdzenia (commit) transakcji A blokada jest utrzymywana tylko podczas wykonywania aktualnego zapytania. S blokada współdzielona (shared) X blokada wyłączna (exclusive) Poziom izolacji Zapis Blokada X Odczyt Blokada S Odczyt zakresu (WHERE ) 0: READ UNCOMMITTED (X S) C A A 1: READ COMMITTED C A A 2: REPEATABLE READ C C A 3: SERIALIZABLE C C C
Zakleszczenia (dead-lock) Przykład: Transakcja T zablokowała daną x i żąda dostępu do danej y. Transakcja S zablokowała daną y i żąda dostępu do danej x. Ani T, ani S nie mogą dalej kontynuować jakiejkolwiek operacji. System zawiesza się. Możliwe są bardziej skomplikowane zakleszczenia:
Wykrywanie zakleszczeń i rozrywanie pętli zakleszczenia Detekcja zakleszczenia wymaga zbudowania grafu czekania i tranzytywnego domknięcia tego grafu. Rozrywanie pętli zakleszczenia polega na wybraniu transakcji ofiary uczestniczącej w zakleszczeniu i następnie jej zerwaniu oraz uruchomieniu od nowa. Wybór ofiary podlega różnym kryteriom, np. transakcja najmłodsza, najmniej pracochłonna, o niskim priorytecie, itp.
Niedopuszczanie do zakleszczeń Wstępne żądanie zasobów (preclaiming): przed uruchomieniem każda transakcja określa potrzebne jej zasoby; nie może później nic więcej żądać. Wada: zgrubne oszacowanie żądanych zasobów prowadzi do zmniejszenia stopnia współbieżności. Czekasz-umieraj (wait-die): jeżeli transakcja próbuje dostać się do zasobu, który jest zablokowany, to natychmiast jest zrywana i powtarzana od nowa. Metoda może być nieskuteczna dla systemów interakcyjnych (użytkownik może się denerwować koniecznością dwukrotnego wprowadzania tych samych danych) oraz prowadzi do spadku efektywności.
Znacznik czasowy - Timestamp Znacznik czasowy TS(T) (timestamp) transakcji T jest jej unikalnym identyfikatorem. Jest to etykieta czasowa nadawana transakcji w momencie jej przybycia do systemu. Znacznik czasowy jest również związany z każdą daną x w bazie danych. Ma on dwie wartości: read_ts(x) - znacznik czasowy transakcji, która ostatnio pomyślnie odczytała daną x write_ts(x) - znacznik czasowy transakcji, która ostatnio pomyślnie zapisała daną x
Algorytm znaczników czasowych Idea algorytmu: każda transakcja pozostawia swój znacznik czasowy przy danej, którą odczytuje lub zapisuje, jeżeli transakcja T chce czytać daną x, a była ona ostatnio zapisywana przez transakcję od niej młodszą (późniejszą), to transakcja T jest odrzucana (bo została wyprzedzona przez młodszą transakcję), jeżeli transakcja T chce zapisać daną x, a była ona ostatnio czytana lub zapisywana przez transakcję młodszą, to transakcja T jest odrzucana. Algorytm ten zapobiega zakleszczeniom.