TECHNIKI STEROWANIA WSPÓŁBIEŻNOŚCIĄ. I. Wybrane problemy współbieżności. Utracona aktualizacja (lost update)



Podobne dokumenty
I. Techniki wielowersyjne sterowania współbieżnością

Bazy danych. Andrzej Łachwa, UJ, /15

Bazy danych 2. Wykład 6 Transakcje

1 Przetwarzanie transakcyjne Cechy transakcji Rozpoczęcie i zakończenie Punkty bezpieczeństwa... 3

przykłady problemów; realizacja dostaw części od producenta do klienta:

070 TRANSAKCJE. Prof. dr hab. Marek Wisła

Ustawienie na poziomie sesji (działa do zmiany lub zakończenia sesji zamknięcia połączenia).

Plan wykładu. Przykład. Wprowadzenie BAZY DANYCH. Transakcje Hurtownie danych

Sprawdzenie poziomu izolacji transakcji (w aktualnym połączeniu):

Bazy danych wykład dziewiaty Transakcje. Konrad Zdanowski ( Uniwersytet Kardynała Stefana Bazy danych Wyszyńskiego, wykładwarszawa)

Wielowersyjne metody synchronizacji transakcji

Algorytmy zarządzania współbieżnym wykonywaniem transakcji część I

Zarządzanie transakcjami

Przechowywanie danych

Transakcje. (c) Instytut Informatyki Politechniki Poznańskiej

BAZY DANYCH. Transakcje. opracowanie: Michał Lech

Tadeusz Pankowski

Plan ćwiczenia. Rozdział 17. zarządzania współbieżnością. Dostęp współbieżny a dostęp spójny. Spójność bazy danych

Algorytmy zarządzania współbieżnym wykonywaniem transakcji część II

Właściwości transakcji

Izolacje transakcji oraz anomalie. Robert A. Kłopotek Wydział Matematyczno-Przyrodniczy. Szkoła Nauk Ścisłych, UKSW

Bazy danych 9. SQL Klucze obce Transakcje

Administracja i programowanie pod Microsoft SQL Server 2000

Wprowadzenie do projektowania i wykorzystania baz danych. Katarzyna Klessa

Wykład V. Indeksy. Struktura indeksu składa się z rekordów o dwóch polach

Rozdział 17. Zarządzanie współbieżnością zadania dodatkowe

Plan ćwiczenia. Rozdział 17 Zarządzanie współbieżnością. Dostęp współbieżny a dostęp spójny. Spójność bazy danych

Tadeusz Pankowski

Wykłady z przedmiotu Podstawy baz danych Transakcje dr hab. prof. UŁ. Tadeusz Antczak. Transakcje

Blaski i cienie wyzwalaczy w relacyjnych bazach danych. Mgr inż. Andrzej Ptasznik

PODSTAWY BAZ DANYCH Wykład 9

Oracle PL/SQL. Paweł Rajba.

Wprowadzenie (1) Przetwarzanie transakcyjne. Wprowadzenie (2) Problemy przygotowania aplikacji

Wykłady z przedmiotu Podstawy baz danych Transakcje dr hab. prof. nadzw. Tadeusz Antczak. Transakcje

Transakcja jest sekwencją logicznie powiązanych operacji na bazie danych, która przeprowadza bazę danych z jednego stanu spójnego w inny stan spójny

Bazy danych. Dr inż. Paweł Kasprowski

Bazy danych w sterowaniu

Bazy danych. Plan wykładu. Czynniki wpływające na fizyczny projekt bazy danych. bazy danych

Rozdział 17. Zarządzanie współbieżnością zadania

Wykład 8. SQL praca z tabelami 5

Ćwiczenie 9 współbieŝność

Systemy operacyjne. wykład 11- Zakleszczenia. dr Marcin Ziółkowski. Instytut Matematyki i Informatyki Akademia im. Jana Długosza w Częstochowie

Porządek dostępu do zasobu: procesory obszary pamięci cykle procesora pliki urządzenia we/wy

Transakcje Wykład z bazy danych dla studen

Internetowe bazy danych

Dazy Banych. Michał Rusnarczyk

Bazy danych 9. Klucze obce Transakcje

Bazy danych 9. Klucze obce Transakcje. P. F. Góra

OLTP Przetwarzanie Transakcyjne

12. Które z harmonogramów transakcji są szeregowalne? a) (a1) (a2) (a3) (a4) b) (b1) (b2) (b3) (b4) c) (c1) (c2) (c3) (c4) d) (d1) (d2) (d3) (d4)

Rozproszone i obiektowe systemy baz danych

PODSTAWY BAZ DANYCH. 11. Transakcje. 2009/ Notatki do wykładu "Podstawy baz danych"

Ćwiczenie 3. Współbieżność i transakcje

INFORMATYKA GEODEZYJNO- KARTOGRAFICZNA. Przetwarzanie transakcyjne

Bazy danych 6a. Transakcje. P. F. Góra

Wykłady z przedmiotu Podstawy baz danych Transakcje dr hab. prof. nadzw. Tadeusz Antczak. Transakcje

E.14 Bazy Danych cz. 18 SQL Funkcje, procedury składowane i wyzwalacze

Microsoft SQL Server Podstawy T-SQL

UPDATE konta /* dodaj do konta B kwotę N */ UPDATE konta /* odejmij kwotę N z konta A */ WHERE id_konta = B; SET stan = stan + N

Informatyka (7-8) dr inż. Katarzyna Palikowska Katedra Transportu Szynowego p. 4 Hydro

Wprowadzenie do projektowania i wykorzystania baz danych Relacje

Transakcje jednocześnie ACID

SQL Server. Odtwarzanie baz danych.

Bazy danych. Zasady konstrukcji baz danych

Paweł Rajba

J. Ułasiewicz Programowanie aplikacji współbieżnych 1

UNIKANIE IMPASÓW W SYSTEMACH PROCESÓW WSPÓŁBIEŻNYCH

Wyzwalacze. do automatycznego generowania wartości kluczy głównych. Składnia instrukcji tworzacej wyzwalacz

Iwona Milczarek, Małgorzata Marcinkiewicz, Tomasz Staszewski. Poznań,

Bazy danych Transakcje

Bazy danych 7. Klucze obce Transakcje. P. F. Góra

Programowanie współbieżne Wykład 7. Iwona Kochaoska

SQL Server i T-SQL w mgnieniu oka : opanuj język zapytań w 10 minut dziennie / Ben Forta. Gliwice, Spis treści

3 Przygotowali: mgr inż. Barbara Łukawska, mgr inż. Maciej Lasota

Zarządzanie obiektami bazy danych Oracle11g

Trigger jest obiektem związanym z tablicą, który aktywuje się gdy do tablicy następuje odpowiednie zapytanie.

Podstawy języka T-SQL : Microsoft SQL Server 2016 i Azure SQL Database / Itzik Ben-Gan. Warszawa, Spis treści

Instrukcja podwaja zarobki osób, których imiona zaczynają się P i dalsze litery alfabetu zakładamy, że takich osbób jest kilkanaście.

DECLARE VARIABLE zmienna1 typ danych; BEGIN

Przeplot. Synchronizacja procesów. Cel i metody synchronizacji procesów. Wątki współbieżne

dr inż. Jarosław Forenc

Podstawy teoretyczne baz danych. Recovery Transakcyjne odtwarzanie bazy danych po awarii

K1A_W11, K1A_W18. Egzamin. wykonanie ćwiczenia lab., sprawdzian po zakończeniu ćwiczeń, egzamin, K1A_W11, K1A_W18 KARTA PRZEDMIOTU

Systemy GIS Tworzenie zapytań w bazach danych

Bazy danych - Materiały do laboratoriów VIII

Przykładowe rozwiązania

T-SQL dla każdego / Alison Balter. Gliwice, cop Spis treści. O autorce 11. Dedykacja 12. Podziękowania 12. Wstęp 15

Wyzwalacze (triggery) Przykład

1 Instalowanie i uaktualnianie serwera SQL Server

koledzy, Jan, Nowak, ul. Niecała 8/23, , Wrocław, , ,

Transakcyjne przetwarzanie danych

w wersji Comarch ERP XL Zmiany techniczne w wersji

Wzorce dystrybucji i wspólbieżności autonomicznej

Administracja i programowanie pod Microsoft SQL Server 2000

Typy tabel serwera MySQL

E.14 Bazy Danych cz. 15 SQL Transakcyjne przetwarzanie danych

PODSTAWY BAZ DANYCH Wykład 6 4. Metody Implementacji Baz Danych

Współbieżność w środowisku Java

Spacery losowe generowanie realizacji procesu losowego

Transkrypt:

TECHNIKI STEROWANIA WSPÓŁBIEŻNOŚCIĄ I. Wybrane problemy współbieżności Utracona aktualizacja (lost update) Przykład: Mąż wybiera 300 zł (ze wspólnego z żoną konta) w bankomacie A, w tym samym czasie żona chce wybrad 100 zł w bankomacie B. Stan konta przed rozpoczęciem transakcji wynosi 2000zł. T i, bankomat A wybierz 300,00 zł K := K - 300 (= 1 700) (utracona aktualizacja) T k, bankomat B wybierz 100,00 zł K := K - 100 (= 1 900) Powyższy harmonogram nie jest szeregowalny. Stan konta po zakooczeniu obydwu transakcji wynosi 1900 zł zamiast 1600 zł. Aktualizacja wykonana przez transakcję T i została utracona mimo, że transakcja ta zakooczyła się powodzeniem (została zatwierdzona). Niespójna analiza (inconsistent analysis). Problemy: czytanie brudnopisu (dirty read) i nie powtarzalne odczyty (non-repeatable read, fuzzy read). Rozważmy trzy konta bankowe: K1, K2, K3. Niech transakcja T i sumuje stan kont, natomiast transakcja T k przelewa 1000 zł z rachunku K3 na rachunek nr K1. Początkowe stany rachunków: K1: 4000 zł K2: 5000 zł K3: 3000 zł Przykład 1: Transakcja T i suma := 0 read (K1) suma := suma + K1 (suma = 4000) Transakcja T k read (K3) (K3 = 3000) K3 := K3 1000 (K3 = 2000) write (K3) 1

read (K2) suma := suma + K2 (suma = 9000) read (K3) (K3 = 2000) suma := suma + K3 (suma = 11000) odczyt wartości niezatwierdzonej read (K1) (K1 = 4000) K1 := K1 + 1000 (K1 = 5000) write (K1) Jeśli transakcja czyta dane z bazy danych w taki sposób, że nie są spełnione warunki ograniczające (constraints) nałożone (jawnie lub niejawnie) na dane, to mówi się, że transakcja doświadcza anomalii związanej z warunkami ograniczającymi (constraint violation concurrency anomaly) i sytuacja taka jest nazywana (wg Date) niespójną analizą (inconsistent analysis). Transakcja T i odczytała niespójny stan bazy danych (odczytała wartośd niezatwierdzoną) i wyliczyła niepoprawną sumę 11 000 zł zamiast 12 000 zł. Odczyt wartości niezatwierdzonej jest nazywany też czytaniem brudnopisu (dirty read), można też spotkad termin brudny odczyt lub brudne czytanie. W powyższym przykładzie przyczyną niespójnej analizy jest czytanie brudnopisu, jednak niespójna analiza nie musi byd związana z czytaniem brudnopisu. Przykład 2: Transakcja T i suma := 0; read (K1) suma := suma + K1 (suma = 4000) read (K2) suma := suma + K2 (suma = 9000) read (K3) (K3 = 2000) suma := suma + K3 (suma = 11000) Transakcja T k read (K3) (K3 = 3000) K3 := K3 1000 (K3 = 2000) write (K3) read (K1) (K1 = 4000) K1 := K1 + 1000 (K1 = 5000) write (K1) Tym razem żadna z transakcji nie przeczytała wartości niezatwierdzonej, jednak znowu transakcja T i wyliczyła niepoprawną sumę 11 000 zł zamiast 12 000 zł. Transakcja T k zmieniła wartośd K1 odczytaną wcześniej przez transakcję T i, co spowodowało, że transakcja T i pracuje na przestarzałych danych. Gdyby transakcja T i przeczytała jeszcze raz K1 już po zatwierdzeniu transakcji T k, otrzymałaby inne dane i to mógłby byd sygnał że są kłopoty i suma będzie niepoprawna. 2

Problem nie powtarzalnych odczytów (non-repeatable reads, fuzzy reads) Problem nie powtarzalnych odczytów (non-repeatable reads, fuzzy reads) można wstępnie sformułowad tak (wrócimy do tego i przedefiniujemy problem nie powtarzalnych odczytów przy okazji omawiania poziomów izolacji transakcji): Pierwsza transakcja odczytuje wiersze, druga je zmienia lub usuwa i wykonuje COMMIT zanim pierwsza wykona COMMIT. Gdyby teraz pierwsza transakcja odczytała wiersze jeszcze raz, to otrzyma inne wyniki. Jak widad wcześniej rozważanego przykładu, kłopoty pojawiają się w rzeczywistości niezależnie od tego, czy transakcja pierwsza odczyta dane powtórnie. Przeanalizujmy jeszcze następujący przykład. Transakcja T i zapisuje stan konta K1 (wiersz w tabeli Tab1) do dwóch różnych elementów danych A i B (mogą to byd inne wiersze w różnych tabelach lub nawet w tej samej tabeli). T i realizuje to przez dwa odczyty stanu konta K1, za pierwszym razem zapisuje stan do elementu A, za drugim do elementu B. (UPDATE Tab2 SET x=(select x FROM Tab1 WHERE klucz1=k1) WHERE klucz2=a i potem UPDATE Tab3 SET x=(select x FROM Tab1 WHERE klucz1=k1) WHERE klucz3=b). Transakcja druga T k wybiera 1000 zł z konta K1. Na początku na koncie K1 jest 4000zł. W wyniku realizacji poniższego harmonogramu stany A i B będą różne (a powinny byd takie same). Transakcja T i read (K1) (K1 = 4000) A := K1 write (A) read (K1) (K1 = 3000) B := K1 write (B) Transakcja T k read (K1) (K1 = 4000) K1 := K1 1000 (K1 = 3000) write (K1) Wiersze widma, fantomy (phantoms) Pierwsza transakcja odczytuje wiersze, które spełniają pewne kryterium wyboru. Druga wstawia nowe wiersze spełniające rozważane kryterium wyboru lub modyfikuje dane tak, że nowe (poza wybranymi wcześniej) wiersze spełniają kryterium. Czytanie brudnopisu (zależnośd od wartości niezatwierdzonej) i rollback Jak powyżej przedstawiono, czytanie brudnopisu może byd powodem niespójnej analizy. Czytanie brudnopisu bywa rozpatrywane w kontekście transakcji kooczącej się wycofaniem. Jest tak np. w definicji ANSI poziomów izolacji transakcji (zagadnienie będzie dokładniej prezentowane później). W rozważanym do tej pory uproszczonym modelu bazy danych przyjęliśmy, że jedyne operacje, które mogą wpłynąd na powstanie niespójnego stanu bazy to operacje Read i Write. Nie rozważaliśmy operacji wycofania (rollback). W takim ujęciu operacja wycofania 3

transakcji powinna byd interpretowana jako zapis before image, czyli wartości sprzed początku transakcji (dotyczy to wszystkich elementów danych zmienionych przez transakcję). Tylko przy tym założeniu możemy uznad, że harmonogramy szeregowalne konfliktowo są poprawne również w obecności operacji rollback. Inaczej harmonogram szeregowalny może doprowadzid do niepoprawnego stanu bazy danych wskutek odczytu wartości niezatwierdzonej (zapisanej przez transakcję, która została wycofana). Operacja rollback może byd wykonywana na różne sposoby, inaczej na przykład w systemie realizującym stronicowanie z zasłanianiem (shadow paging), inaczej w takim systemie z dziennikiem transakcji, który w przypadku wycofania transakcji zapisuje wartości sprzed początku transakcji (before image). To zagadnienie też będzie jeszcze dokładniej przedstawiane w dalszej części wykładu z baz danych. Teraz warto wspomnied, że np. stronicowanie z zasłanianiem (różne odmiany) i systemy z wielowersyjnym sterowaniem transakcjami (są różne wersje tego samego elementu danych) uniemożliwiają odczyt wartości niezatwierdzonych. Poniżej rozważymy system z zapisem wartości początkowych (before images). Przykład. Mąż wybiera 300 zł (ze wspólnego z żoną konta) w bankomacie A, w tym samym czasie żona chce wybrad 100 zł w bankomacie B. Stan konta przed rozpoczęciem transakcji wynosi 2000zł. T i bankomat A wybierz 300,00 zł K := K - 300 (K = 1 700) odczyt wartości niezatwierdzonej rollback T k bankomat B K = 1 700,00 wybierz 100,00 zł K := K - 100 (= 1 600) Stan konta po zakooczeniu obydwu transakcji wynosi 1600 zł zamiast 1900 zł (wybrano tylko 100 zł). Zakładamy tu, że system działa tak, że wycofanie transakcji T i nie powoduje automatycznego kaskadowego wycofania transakcji T k (mimo, że T k czyta z T i ). Jest tak np. w systemie Microsoft SQL Server w poziomie izolacji transakcji READ UNCOMMITTED. Operację rollback można tu rozumied jako zapisanie wartości K sprzed wykonania transakcji i zakooczenie wykonywania transakcji. T i bankomat A T k bankomat B 4

wybierz 300,00 zł K := K - 300 (K = 1 700) odczyt wartości niezatwierdzonej (K=2000) end () K = 1 700,00 wybierz 100,00 zł K := K - 100 (= 1 600) Harmonogram nie jest szeregowalny. Niepoprawne wyniki da również taki harmonogram: T i bankomat A wybierz 300,00 zł K := K - 300 (K = 1 700) odczyt wartości niezatwierdzonej rollback T k bankomat B K = 1 700,00 wybierz 100,00 zł K := K - 100 (= 1 600) Harmonogram ten mógłby byd realizowany tak: T i bankomat A wybierz 300,00 zł K := K - 300 (K = 1 700) odczyt wartości niezatwierdzonej (K=2000) end () T k bankomat B K = 1 700,00 wybierz 100,00 zł K := K - 100 (= 1 600) Pomimo wybrania 100 zł na koncie pozostaje 2000, wystąpił problem utraconej aktualizacji. 5

II. Techniki sterowania współbieżnością wykorzystujące blokowanie. Protokół dwufazowego blokowania (2PL). Blokada (lock) jest zmienną związaną z elementem danych, która opisuje stan tego elementu pod względem możliwości działao, jakie mogą byd na nim w danej chwili wykonywane. Blokowanie binarne element wolny lub zablokowany. Wada: mała efektywnośd operacji współbieżnych. Propozycja dwóch typów blokad: Blokady wyłączne (typu X, exclusive, blokady do zapisu) Blokady wspólne (typu S, shared, blokady do odczytu) Na początek dla uproszczenia załóżmy, że blokujemy zawsze wiersze (nie tabele, bloki itp.). Zasady: 1. Jeśli transakcja A założy blokadę wyłączną (X) na wiersz p, to próba założenia jakiejkolwiek blokady przez inną transakcję B na tym samym wierszu zostanie oddalona. 2. Jeśli transakcja A założy blokadę wspólną (S) na wiersz p, to: próba założenia blokady wyłącznej (X) przez transakcję B na tym samym wierszu zostanie oddalona, próba założenia blokady wspólnej (S) przez transakcję B na tym samym wierszu zostanie zaakceptowana - transakcja B też będzie utrzymywad blokadę na p. Macierz kompatybilności dla blokad typu X i S. X S bez blokady X Nie Nie Tak S Nie Tak Tak bez blokady Tak Tak Tak Propozycja protokołu dostępu do danych, zapobiegającego wcześniej przedstawionym problemom współbieżności: rygorystyczny protokół dwufazowego blokowania (rigorous 2PL- 2 Phase Locking) 1. Transakcja, która chce uzyskad dostęp do wiersza, musi najpierw uzyskad blokadę S na tym wierszu. 2. Transakcja, która chce zmodyfikowad wiersz, musi najpierw uzyskad blokadę X na tym wierszu. Jeśli transakcja już wcześniej założyła blokadę S, to musi ona zmienid blokadę (zaktualizowad, upgrade) z S na X. 3. Jeśli żądanie blokady pochodzące od transakcji B zostanie odrzucone ze względu na to, że jest w konflikcie z blokadą założoną wcześniej przez transakcję A, to transakcja B przechodzi w stan oczekiwania. Stan ten potrwa do momentu, aż blokada związana z 6

transakcją A zostanie zdjęta. System powinien zapewnid, że transakcja B nie będzie czekała w nieskooczonośd (żeby nie nastąpiło zagłodzenie). 4. Blokady S i X są utrzymywane do kooca transakcji (tj. do polecenia COMMIT lub ROLLBACK). W literaturze można spotkad wersję tego protokołu bez stosowania zmiany blokady z S na X, tzn. transakcja, która chce czytad element danych i będzie później modyfikowała ten element, zakłada od razu blokadę typu X. Ponowna analiza wybranych problemów współbieżności Problem utraconej aktualizacji T i bankomat A (zakłada blokadę S na K) wybierz 300,00 zł K := K - 300 (= 1 700) (żąda blokady X na K) T k bankomat B (zakłada blokadę S na K) wybierz 100,00 zł K := K - 100 (= 1 900) (żąda blokady X na K) Problemu niespójności nie ma, ale pojawił się nowy zakleszczenie (wzajemna blokada, deadlock). Niespójna analiza Rozważmy trzy konta bankowe: K1, K2, K3. Niech transakcja A sumuje stan kont, natomiast transakcja B przelewa 1000 zł z rachunku K3 na rachunek nr K1. Początkowe stany rachunków: K1: 4000 zł K2: 5000 zł K3: 3000 zł Przykład 1: Transakcja T i suma := 0 read (K1) (zakłada blokadę S na K1) Transakcja T k read (K3) (K3 = 3000) (zakłada blokadę S na K3) K3 := K3 1000 (K3 = 2000) write (K3) (zmienia blokadę z S na X dla K3) 7

suma := suma + K1 (suma = 4000) read (K2) (zakłada blokadę S na K2) suma := suma + K2 (suma = 9000) read (K3) (K3 = 2000) (próbuje założyd blokadę S na K3) read (K1) (K1 = 4000) (zakłada blokadę S na K1) K1 := K1 + 1000 (K1 = 5000) write (K1) (próbuje zmienid blokadę z S na X) Pojawiło się zakleszczenie, ale transakcje nie doprowadzają do niespójnego stanu bazy danych. Przykład 2: Transakcja T i suma := 0; read (K1) (zakłada blokadę S na K1) suma := suma + K1 (suma = 4000) read (K2) (zakłada blokadę S na K2) suma := suma + K2 (suma = 9000) read (K3) (K3 = 2000) (próbuje założyd blokadę S na K3) Transakcja T k read (K3) (K3 = 3000) (zakłada blokadę S na K3) K3 := K3 1000 (K3 = 2000) write (K3) (zmienia blokadę z S na X dla K3) read (K1) (K1 = 4000) (zakłada blokadę S na K1) K1 := K1 + 1000 (K1 = 5000) write (K1) (próbuje zmienid blokadę z S na X dla K1) Pojawiło się zakleszczenie, ale transakcje nie doprowadzają do niespójnego stanu bazy danych. 8

Nie powtarzalne odczyty Tym razem zanim druga transakcja będzie mogła zmienid dane, musi uzyskad blokadę wyłączną, a nie jest to możliwe aż do zakooczenia transakcji pierwszej. Dopiero po zakooczeniu pierwszej transakcji nastąpi modyfikacja w transakcji drugiej. Transakcja T i read (K1) (K1 = 4000) (zakłada blokadę S na K1) A := K1 write (A) (zakłada blokadę X na A) read (K1) (K1 = 4000) B := K1 write (B) (zakłada blokadę X na B) (zwalnia wszystkie blokady) Transakcja T k read (K1) (K1 = 4000) (zakłada blokadę S na K1) K1 := K1 1000 (K1 = 3000) write (K1) (próbuje zmienid blokadę S na X dla K1) następuje przydzielenie blokady X na K1 dla transakcji T k zrealizowana zostaje operacja zapisu write(k1) Wiersze widma (fantomy, phantoms) W dotychczasowych rozważaniach nie przyglądaliśmy się bliżej co to znaczy element danych. Jeśli w przyjętym przez nas uproszczonym modelu bazy danych element danych będzie oznaczał konkretny wiersz i blokady dotyczą konkretnego zapisanego w tabeli wiersza, to 2PL w wersji podanej powyżej nie zabezpiecza przed fantomami. Jeśli jednak będziemy chcieli odzwierciedlid w modelu odczyty danych w wykorzystaniem pewnego predykatu (warunek WHERE w zdaniu SELECT), to należałoby wprowadzid tzw. blokady predykatowe. Założenie blokady predykatowej na element A (zbiór wierszy spełniających warunek WHERE) można rozumied jako zablokowanie tego zbioru w taki sposób, że zbiór nie będzie mógł byd w żaden sposób zmieniony przez inną transakcję (INSERT, DELETE, UPDATE). Przy takich założeniach stosowanie protokołu 2PL zabezpiecza przed fantomami. Czytanie brudnopisu, zależnośd od wartości niezatwierdzonej T i bankomat A (zakłada blokadę S na K) wybierz 300,00 zł K := K - 300 (= 1 700) (zmienia blokadę z S na X dla K) T k bankomat B 9

rollback (zwalnia wszystkie blokady przydzielone do transakcji T i ) (żąda blokady S na K) zostaje założona blokada S na K i następuje odczyt K, K=2000 wybierz 100,00 zł K := K - 100 (= 1 900) (zmienia blokadę z S na X dla K) (zwalnia wszystkie blokady przydzielone do transakcji T k ) Stan konta po zakooczeniu obydwu transakcji wynosi 1900 zł. Różne wersje protokołu dwufazowego blokowania Wersja podstawowa protokołu dwufazowego blokowania (basic 2PL): 1. Zanim transakcja rozpocznie działanie na pewnym obiekcie w bazie danych, musi założyd na ten obiekt odpowiednią blokadę (S lub X). 2. Po zwolnieniu blokady transakcja już nie może zakładad żadnej nowej blokady na jakikolwiek obiekt. Blokady mogą byd wcześniej zwalniane (niekoniecznie na koocu transakcji). Inne wersje protokołu dwufazowego blokowania Ścisły protokół 2PL (strict 2PL): podobnie jak rygorystyczny, ale do kooca transakcji utrzymywane są tylko blokady wyłączne. Blokady S mogą byd zwalniane wcześniej. Jest trudniejszy do zaimplementowania niż rygorystyczny 2PL, ale obydwa gwarantują występowanie ścisłych harmonogramów. W obydwu mogą wystąpid zakleszczenia. Konserwatywny protokół 2PL (conservative 2PL): na początku transakcja musi określid zbiór elementów, które chce blokowad. Jeśli można zablokowad wszystkie, to elementy są blokowane, jeśli nie, to po pewnym czasie próba jest ponawiana. Ta wersja protokołu 2PL daje gwarancję braku zakleszczeo. Twierdzenie Jeśli wszystkie transakcje spełniają protokół dwufazowego blokowania (wersję podstawową lub inne), to wszystkie (przeplatane) harmonogramy są szeregowalne konfliktowo. Jeśli transakcja A nie spełnia protokołu dwufazowego blokowania (ale stosowane są blokady S i X według wcześniej podanych reguł), to zawsze można utworzyd pewną transakcję B, która przeplata się z A tak, że daje to harmonogram, który nie jest szeregowalny konfliktowo. 10

III. Zakleszczenia Zakleszczenie (deadlock) występuje wówczas, gdy każda transakcja T ze zbioru dwóch lub więcej transakcji oczekuje na pewien element zablokowany przez inną transakcję T z tego zbioru. Protokoły zapobiegania zakleszczeniom (deadlock prevention protocols) Protokoły tego typu są rzadko wykorzystywane w praktyce. Zarządca transakcji sprawdza na początku, czy transakcja może spowodowad zakleszczenie. Jeśli tak, to transakcja nie jest wykonywana. Po pewnym czasie następuje ponowna próba wykonania transakcji. Konserwatywny protokół blokowania dwufazowego jest przykładem protokołu zapobiegającego zakleszczeniom. Protokoły unikania zakleszczeo (deadlock avoidance protocols) Propozycja 1 Uporządkowanie wszystkich elementów w bazie danych i zapewnienie, aby każda transakcja wymagająca dostępu do kilku elementów realizowała dostępy i blokowała elementy w odpowiedniej kolejności (wszystkie transakcje w tej samej kolejności). Na ogół w bazach danych taka strategia nie może byd zastosowana. Propozycja 2 Wykorzystanie znaczników czasu, wersja Czekaj-koocz (WAIT-DIE) TS(T) znacznik czasu transakcji (transaction timestamp), rosnące numery lub np. data z godziną rozpoczęcia transakcji. Załóżmy, że transakcja T i próbuje zablokowad element danych, który jest już blokowany przez inną transakcję T k z użyciem konfliktowej blokady. Strategia: Jeżeli TS(T i ) < TS(T k ) (T i jest starsza, tzn. rozpoczęła się wcześniej), wówczas T i czeka, w przeciwnym przypadku (T i jest młodsza) T i jest anulowana i ponawiana później z tym samym znacznikiem czasu. Propozycja 3 Wykorzystanie znaczników czasu, wersja Zakoocz-czekaj (WOUND-WAIT) Załóżmy, że transakcja T i próbuje zablokowad element danych, który jest już blokowany przez inną transakcję T k z użyciem konfliktowej blokady. Strategia: Jeżeli TS(T i ) < TS(T k ) (T i jest starsza, tzn. rozpoczęła się wcześniej), wówczas T k zostaje anulowana i ponawiana później z tym samym znacznikiem czasu, w przeciwnym przypadku (T i jest młodsza) T i czeka. W obu powyższych strategiach (tzn. z propozycji 2 i 3) anulowana jest młodsza transakcja. Jednak strategia Czekaj-koocz preferuje w pewien sposób transakcje młodsze, gdyż młodsza 11

transakcja T k nie jest przerywana, a starsza czeka na jej zakooczenie. Strategia Zakooczczekaj preferuje w pewien sposób transakcje starsze. Propozycja 4 Strategia bez oczekiwania (no wait) jeśli transakcja nie może założyd blokady, to jest wycofywana (i potem wznawiana) bez sprawdzania, czy zakleszczenie rzeczywiście mogłoby wystąpid, czy nie. Propozycja 5 Strategia oczekiwania ostrożnego (cautious waiting). Załóżmy, że transakcja T i próbuje zablokowad element danych, który jest już blokowany przez inną transakcję T k z użyciem konfliktowej blokady. Jeśli T k nie czeka na pewien inny zablokowany element, to transakcja T i będzie czekad, w przeciwnym przypadku transakcja T i jest anulowana. Wykrywanie zakleszczeo (deadlock detection) Propozycja 1 Skonstruowanie grafu oczekiwania (wait-for graph). Dla każdej wykonywanej transakcji tworzony jest wierzchołek w grafie. Jeśli transakcja T i próbuje zablokowad element danych, który jest już blokowany przez inną transakcję T k z użyciem konfliktowej blokady, w grafie jest tworzona krawędź skierowana z T i do T k. Po zwolnieniu blokady krawędź jest usuwana. Cykl w grafie oznacza zakleszczenie. Wybór ofiary na ofiarę można wybrad transakcję młodszą, lub tę, która mniej zmodyfikowała (tę, której wycofanie jest prostsze). Propozycja 2 Użycie limitów czasu (timeouts) jeśli transakcja czeka na zasób dłużej niż przyjęta wartośd progowa, to system przyjmuje, że uległa zakleszczeniu i anuluje ją, bez względu na to, czy zakleszczenie rzeczywiście wystąpiło, czy nie. Blokady typu U Blokada U (od: Update) jest stosowana w przypadku, gdy element danych jest odczytywany i byd może będzie potem aktualizowany. Jeśli w takim przypadku stosowana jest blokada S i potem zmieniana jest na X, może to prowadzid do zakleszczenia. Rozwiązaniem może byd wprowadzenie blokady do aktualizacji U, która jest kompatybilna z S a nie jest kompatybilna z X ani U. Rozważa się dwie wersje blokad U. 12

Wersja 1: Blokada, która S X U ma byd przyznana: Już przyznana blokada: S Tak Nie Tak X Nie Nie Nie U Tak Nie Nie Wersja 2: Blokada, która S X U ma byd przyznana: Już przyznana blokada: S Tak Nie Tak X Nie Nie Nie U Nie Nie Nie Blokada U jest zakładana przy odczycie (w celu późniejszej aktualizacji). Przed wykonaniem aktualizacji danych blokada U jest konwertowana do X (zatem wszystkie blokady S muszą zostad zdjęte). Unikanie zagłodzenia Strategie Czekaj-koocz i Zakoocz-czekaj nie powodują zagłodzenia. Przykładowe inne strategie kolejka FCFS, zwiększanie priorytetu w miarę czasu oczekiwania, zwiększanie priorytetu dla transakcji wielokrotnie wycofywanej. 13

IV. Techniki sterowania współbieżnością z wykorzystaniem znaczników czasu Tworzony harmonogram jest równoważny konfliktowo konkretnemu uporządkowaniu szeregowemu, odpowiadającemu porządkowi znaczników czasu transakcji (TS(T)). Oprócz znaczników czasu transakcji wprowadźmy znaczniki czasu elementów danych. TS_odczytu(X). Znacznik czasu odczytu (read timestamp) elementu danych X jest to znacznik o najwyższej wartości spośród wszystkich znaczników transakcji, które z powodzeniem odczytały element X. TS_odczytu(X)=TS(T), gdzie T jest najmłodszą transakcją, która z powodzeniem odczytała element X. TS_zapisu(X). Znacznik czasu zapisu (write timestamp) elementu danych X ma wartośd równą najwyższej wartości znacznika transakcji spośród wszystkich znaczników transakcji, które z powodzeniem zapisały element X. TS_zapisu(X)=TS(T), gdzie T jest najmłodszą transakcją, która z powodzeniem zapisała element X. Algorytm porządkowania według znaczników czasu Wersja podstawowa Podstawowy algorytm porządkowania według znaczników czasu: jeśli wykryje dwie operacje konfliktowe występujące w niepoprawnej kolejności, to odrzuca późniejszą z tych operacji i anuluje transakcję, która tę operację wykonywała. Jeśli transakcja jest wycofana, to jest później ponawiana z nowym znacznikiem czasu. Należy rozważyd dwa przypadki: 1. Transakcja T wykonuje operację zapisz_element(x): a) Jeśli TS_odczytu(X) > TS(T) lub TS_zapisu(X)>TS(T), to operacja zapisu jest odrzucona i transakcja T wycofana. b) Jeśli warunek z punktu a) nie jest spełniony, wykonywana jest operacja zapisz_element(x) i wartośd TS_zapisu(X) ustawiana jest na TS(T). 2. Transakcja T wykonuje operację odczytaj_element(x): a) Jeśli TS_zapisu(X) > TS(T), to operacja odczytu jest odrzucona i transakcja T zostaje wycofana. b) Jeśli TS_zapisu(X) <= TS(T), to wykonywana jest operacja odczytaj_element(x) w transakcji T i wartośd TS_odczytu(X) ustawiana jest na większą z wartości TS(T) lub bieżącej wartośd TS_odczytu(X). Zakleszczenie nie występuje, natomiast może pojawid się zagłodzenie w przypadku, gdy transakcja jest stale anulowana i ponawiana. 14

Powyższy algorytm nie uwzględnia operacji wycofania i harmonogramy mogą doświadczad problemów związanych z odczytem wartości niezatwierdzonych. Aby tego uniknąd można wprowadzid dodatkowe mechanizmy. Ścisłe porządkowanie według znaczników czasu Zapewnia, że harmonogram jest nie tylko szeregowalny, ale ścisły. Transakcja T, taka że TS(T) > TS_zapisu(X), która wykonuje operację odczytaj_element(x) lub zapisz_element(x), opóźnia ją do momentu aż transakcja T, która zapisała wartośd X (czyli TS(T )=TS_zapisu(X)), zostanie zatwierdzona lub anulowana. Zakleszczenie nie występuje. Nie ma też problemów z odczytem tych niezatwierdzonych wartości, które są wycofywane. Reguła zapisu Thomasa Nie wymusza szeregowalności konfliktowej, ale odrzuca mniejszą liczbę operacji zapisu niż podstawowa wersja. Zmodyfikowane jest sprawdzanie operacji zapisz_element(x): 1. Jeśli TS_odczytu(X) > TS(T), to operacja zapisu jest odrzucona i transakcja T jest anulowana. 2. Jeśli TS_zapisu(X) > TS(T), to operacja zapisu nie jest wykonywana, ale transakcja jest kontynuowana. 3. Jeśli nie wystąpi sytuacja ani z punktu 1. ani z punktu 2., to operacja zapisz_element(x) w transakcji T jest wykonywana i wartośd TS_zapisu(X) jest ustawiana na TS(T). 15