Transakcje w bazie danych

SYSTEMY BAZ DANYCH
Część IV
Wprowadzenie do transakcji w bazach danych
Opracowanie : Dr Bożena Śmiałkowska
Definicja transakcji
2
Co to są transakcje?
• Transakcja to podstawowa logiczna jednostka interakcji
użytkownika z systemem bazy danych
• Transakcja to sekwencja operacji, która musi zakończyć
się sukcesem w całości – w przeciwnym wypadku
przywrócony musi być stan początkowy
Przykład transakcji:
Operacja przelewu kwoty x z konta A na konto B:
1) Pobranie kwoty x z konta A
2) Dodanie kwoty x do konta B
3
Co to są transakcje? ..
• Przykład zastosowania: musimy wykonać
kilka komend SQL zmieniających dane w
tablicach. Jak to zrobić aby komendy wykonał
się poprawnie do końca albo wcale?
• Transakcja jest logiczną jednostką działań,
której nie można podzielić.
• Logiczna jednostka działań to zbiór
logicznych zmian w bazie danych, które
należy wykonać wszystkie albo nie
wykonywać żadnej.
4
Co to są transakcje?
• W języku PostgreSQL zmiany te są kontrolowane przez
trzy kluczowe frazy:
– Fraza BEGIN WORK rozpoczyna transakcję;
– COMMIT WORK informuje, że wszystkie elementy
transakcji są kompletne i powinny zostać zatwierdzone
na stałe oraz stać się dostępne dla wszystkich
transakcji;
– ROLLBACK WORK mówi, że należy porzucić
transakcję, a wszystkie zmiany danych dokonane przez
transakcję SQL mają być anulowane. Baza danych, z
punktu widzenia użytkowników, powinna się znajdować
w takim stanie, jakby nie były wykonywane żadne
zmiany.
5
Co to są transakcje?
• 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.
• Niestety realia związane z osiągnięciem
dobrej wydajności wymagają kompromisów
o których powiemy później.
6
Trzeba uważać aby nie wpaść w
pewną pułapkę?
KLIENT 1
KLIENT 2
Czy są wolne miejsca?
1
Czy są wolne miejsca?
Oferuje miejsce
1
1
Oferuje miejsce
Pytanie o kartę kredytową lub konto
Podaje numer karty
Wolne miejsce
1
1
Pytanie o kartę kredytową lub konto
1
Podaje numer konta
1
Autoryzacja
1
Autoryzacja
Przypisanie miejsca
1
1
Przypisanie miejsca
Obciążenie karty
1
1
Obciążenie karty
Zmniejszenie liczby wolnych miejsc
1
0
Zmniejszenie liczby wolnych miejsc
-1
7
Trzeba uważać aby nie wpaść w
pewną pułapkę?
• Złe rozwiązania:
– Pozwalamy tylko jednemu klientowi korzystać
w jednej chwili z aplikacji co powoduje słabą
wydajność.
– Piszemy aplikację z techniką semaforową.
Semafor ochrania dekrementacje zmiennej
liczba biletów.
• Jak to rozwiązać???
8
Przykład transakcji
9
Przykład transakcji cd..
Każde wykonanie programu
PRZELEW_PKO_WBK
powoduje utworzenie nowej
transakcji.
10
Przykład transakcji cd..
11
Przykładowa transakcja cd..
(begin transaction);
Zidentyfikuj klienta;
Jeżeli nie da się zidentyfikować to zerwij (abort);
Wczytaj zlecenie wypłaty;
Sprawdź konto klienta;
Jeżeli konto < zlecenia to
komunikat o przekroczeniu konta;
zerwij (abort);
Wyślij zlecenie do kasy;
Jeżeli upłynął czas większy od 5 minut to
cofnij zlecenie do kasy;
zerwij transakcję (abort);
Jeżeli kasjer potwierdził dokonanie wypłaty to
potwierdź transakcję (commit)
a inaczej
cofnij zlecenie do kasy;
zerwij (abort);
Transakcja, która
zaczęła się w systemie
jest identyfikowana
jako specjalny byt; jest
jej nadawany unikalny
numer (identyfikator).
abort - kasowanie
transakcji i wszelkich
skutków które ona
poczyniła
commit - wprowadzenie
skutków transakcji na
dysk i skasowanie
transakcji
Takie programy mogą być proste lub dowolnie skomplikowane.
Z tego względu miara liczba transakcji/sekundę jest często mało wiarygodna.
12
Po co są transakcje? – są środkiem na
rozwiązanie problemu współbieżności
Załóżmy, że na bazie danych działa wiele procesów jednocześnie. Dla przykładu niech
będą dwa procesy A i B, które będą działać na bazie danych i wykonują odczyt
atrybutu X, zwiększenie wartości oraz zapis.
Czas Proces A
1
2
3
4
5
6
Proces B Wartość XA Wartość XB
Czyta X
5
Czyta X 5
X :=X+1
6
X := X+1 6
Zapisuje X
6
Zapisuje X6
5
5
6
6
6
Jeżeli te dwa procesy działałyby niezależnie a X=5 przed rozpoczęciem procesu to wynik
powinien w X być 7. Działając równolegle i nie synchronizując swoich akcji jedna
aktualizacja została zgubiona.
Inny przykład: mamy kilku użytkowników chcąc równolegle aktualizować pewien tekst.
Jeżeli nie umówią się, który z nich aktualnie ma prawo wprowadzać poprawki, to
część poprawek może zostać zgubiona.
Transakcje do baz danych wprowadza się po to by umożliwić współbieżne działanie na13bazie
Danych. Można wówczas uzyskać spójność działania bez potrzeby umawiania się.
Po co są transakcje? - przeciwdziałają
awariom
Załóżmy, że mamy system bankowy, w którym następują operacje na kontach klientów
w sposób następujący:
1. Klient wczytuje kartę magnetyczną i jest rozpoznawany
2. Klient określa sumę wypłaty
3. Konto klienta jest sprawdzane
4. Konto jest zmniejszane o sumę wypłaty
5. Wysyłane jest zlecenie do kasy
6. Kasjerka odlicza sumę wypłaty od stanu kasy
7. Kasjerka wypłaca klientowi pieniądze
Normalnie, aby klient
dostał swoje pieniądze,
tego rodzaju operacji
wykonuje się kilkadziesiąt.
Prawdopodobieństwo różnych
awarii jest spore.
Pytanie: co się stanie, jeżeli pomiędzy operacją 4 i 5 wyłączą światło?
(Konto zostało zmniejszone, klient nie dostał pieniędzy….
Transakcje: umożliwiają uniknięcie tego rodzaju nieprzyjemnych sytuacji
związanych z dowolnymi awariami sprzętu, błędów w oprogramowaniu,
a nawet tego, że kasjerka poczuła się niedobrze i musiała wyjść.
14
Własności transakcji
Nie mylić pojęcia transakcji z procedurą! Transakcja angażuje bieżące zasoby systemu
takie jak czas i dane. Wywołanie procedury może być transakcją, ale może ona też
składać się z wielu wywołań procedur i jedno wywołanie może generować wiele
transakcji. Transakcje mogą obejść się w ogóle bez procedur.
Własności transakcji: ACID
A
Atomowość (atomicity) - w ramach jednej transakcji wykonują się albo
wszystkie operacje, albo żadna
Spójność (consistency) - o ile transakcja zastała bazę danych w spójnym stanie,
C
I
D
po jej zakończeniu stan jest również spójny. (W międzyczasie stan może być
chwilowo niespójny)
Izolacja (isolation) - transakcja nie wie nic o innych transakcjach i nie musi
uwzględniać ich działania. Czynności wykonane przez daną transakcję są
niewidoczne dla innych transakcji aż do jej zakończenia.
Trwałość (durability) - po zakończeniu transakcji jej skutki są na trwale
15
zapamiętane (na dysku) i nie mogą być odwrócone przez zdarzenia losowe (np.
wyłączenie prądu)
Własności transakcji cd..
16
Dwufazowe zatwierdzanie
Dla zapewnienia własności atomowości transakcji
rozproszonych opracowano protokół zatwierdzania
dwufazowego (ang 2-Phase Commit)
• Faza 1 – Prepare: węzły (serwery) biorące udział w
transakcji przygotowują się do jej zatwierdzenia (na
żądanie koordynatora transakcji)
• Faza 2 – Commit: gdy wszystkie węzły są gotowe
do zatwierdzenia transakcji następuje jej rzeczywiste
zatwierdzenie
17
Jak realizuje się transakcje?
• Standard ANSI/SQL nie definiuje frazy
SQL
BEGIN WORK, transakcje w tym
standardzie powinny wykonywać się
automatycznie. Fraza ta jednak jest
wymagana prawie we wszystkich
implementacjach baz danych.
• Słowo WORK we frazie COMMIT WORK,
ROLLBACK WORK można pominąć.
18
Własności transakcji cd..
19
Własności transakcji cd..
20
Własności transakcji cd..
21
Kryterium poprawności transakcji
Współbieżne wykonanie transakcji jest poprawne wtedy i tylko wtedy jeżeli jego efekt
jest dokładnie taki sam jak efekt wykonania tych transakcji pojedynczo po kolei.
Ta własność nosi nazwę szeregowalności (serializability)
Plan wykonania transakcji:
- Transakcje rozbija się na mniejsze fragmenty zwane operacjami.
- Plan ustala jak po kolei mają być wykonywane operacje z poszczególnych transakcji.
-Plan jest szeregowalny, jeżeli jego końcowy efekt jest taki sam, jak wykonanie
transakcji po kolei.
Istnieje matematyczna teoria szeregowalności transakcji, wiele osób na nią się powołuje, ale
znacznie mniej wie, o co w niej chodzi. (Ja nie miałem cierpliwości do tej teorii...) Są opinie, że ta
teoria (jak większość teorii) jest mało przydatna, ponieważ dla cokolwiek bardziej
skomplikowanych planów wykonania transakcji nic się nie da udowodnić (trzeba i tak
zaimplementować lub zasymulować).
Istnieją też opinie (Mohan) że teoria nie obejmuje ważnych przypadków takich jak usuwanie
danych.
Problemy: znaleźć szeregowalny plan o minimalnym totalnym koszcie
znaleźć szeregowalny plan gdzie czas odpowiedzi nie jest dłuższy niż t,
....
22
Przetwarzanie transakcji
Menadżer transakcji (MT) koordynuje wykonywanie transakcji.
Decyduje do jakiego menadżera danych (MD) przekazuje operację
transakcji.
Operacja przyjmuje planista związany z MD i zarządza ich
wykonywaniem posługuje się protokółem np.: dwu-fazowego
blokowania.
23
Działanie planisty
Planista przyjmując operację ma do dyspozycji następujące
działania:
Przekazać operację do wykonania menadżerowi danych,
Umieszczenie operacji w kolejce, jeśli znajduje się ona w konflikcie z
inną operacją i należy poczekać na zakończenie tej operacji,
Odrzucenie operacji i tym samym całej transakcji, jeśli np. konieczne
jest to z punktu widzenia rozwiązywania zakleszczeń (dead locs),
Opisana strategia działania planisty jest w komercyjnych systemach
DBMS realizowana za pomocą tzw. protokółu dwu-fazowego
blokowania. Planista realizujący te strategię nazywany jest planistą
blokowania dwufazowego.
24
Implementacja 2PL
(dwufazowe blokowanie)
Zamek (lock): jedna z transakcji rezerwuje sobie dostęp do obiektu.
X
S
Inne transakcje nie mają dostępu lub mają dostęp ograniczony.
Wyłączny zamek (exclusive lock): transakcja zablokowuje jakikolwiek
dostęp do obiektu dla innych transakcji.
Dzielony zamek (shared lock): inne transakcje mogą czytać, ale nie mogą
modyfikować.
Udowodniono (szczególnie, że dla każdego jest to oczywiste :-), że szeregowalność jest
zachowana, jeżeli cała transakcja ma dwie fazy: rosnącą i skracającą.
start
Protokół 2PL
potwierdzenie
(commit)
koniec
(two-phase locking)
zakładanie zamków
(nie ma zwalniania)
zwalnianie
zamków (nie
ma zakładania)
czas
Awarie są możliwe w obydwu fazach, ale faza commit jest szybka (milisekundy).
25
Implementacja 2PL…
26
Implementacja 2PL…
27
Zakleszczenie
Koncepcja zamków prowadzi do nieprzyjemnego efektu zwanego zakleszczeniem.
Transakcja A zablokowała zasób X i żąda dostępu do zasobu Y
Transakcja B zablokowała zasób Y i żąda dostępu do zasobu X.
Ani A, ani B nie mogą dalej kontynuować jakiejkolwiek akcji. (System “zawiesił się’.)
Możliwe są bardziej skomplikowane sytuacje związane z zakleszczeniem:
W pętli zakleszczenia są 3 transakcje:
Transakcja B
Transakcja A
Transakcja C
Zakleszczyły się dwie transakcje,
pozostałe działają normalnie:
Transakcja B
Transakcja A
Transakcja C
28
Walka z zakleszczeniem
Bardzo poważny problem, mający skutki zarówno dla wydajności systemu jak i
spójności działania (szczególnie w systemach czasu rzeczywistego, np. w bankach).
Dwie generalne metody:
1. Wykrywanie zakleszczeń i rozrywanie pętli zakleszczenia. Detekcja zakleszczenia
wymaga skonstruowania grafu czekania (wait-for graph) i tranzytywnego
domknięcia tego grafu (złożoność gorsza niż n * n). Rozrywanie pętli
zakleszczenia polega na wybraniu transakcji “ofiary” uczestniczącej w
zakleszczeniu i następnie, jej zerwaniu i uruchomieniu od nowa. Wybór “ofiary”
podlega różnym kryteriom - np. najmłodsza, najmniej pracochłonna, o niskim
priorytecie, itd.
2. Nie dopuszczanie do zakleszczeń. Istnieje wiele tego rodzaju metod, np.
a) 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.
b) 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)
29
oraz prowadzi do spadku efektywności (sporo pracy idzie na marne).
Metody bez zakleszczeń oparte na
stemplach czasowych
Każda transakcja w momencie startu dostaje unikalny stempel czasowy, na tyle
precyzyjny, aby móc po stemplach rozróżniać transakcje.
Żadna zmiana nie jest nanoszona do bazy danych; transakcja działa na swoich
własnych kopiach, aż do potwierdzenia.
Każdy obiekt bazy danych przechowuje 2 stemple czasowe: transakcji, która ostatnio
brała obiekt do czytania i transakcja, która ostatnio brała obiekt do modyfikacji.
W momencie potwierdzenia sprawdza się stemple transakcji oraz wszystkich
pobranych przez nią obiektów. Można dość łatwo wyprowadzić reguły zgodności, np.
Jeżeli obiekt był aktualizowany i stempel na obiekcie do aktualizacji jest taki sam jak
stempel transakcji, to OK, a inaczej zerwij i uruchom od nowa.
Jeżeli obiekt był tylko czytany i stempel na obiekcie do aktualizacji jest starszy niż
stempel transakcji, to OK; inaczej zerwij i uruchom od nowa.
.... (trochę dalszych reguł).
Metoda jest o tyle przyjemna, że zerwanie transakcji oznacza zlikwidowanie tylko
lokalnych kopii obiektów - nie potrzeba nic robić w bazie danych.
30
Metody optymistyczne
Zasada podobna jak w przypadku stempli czasowych, ale transakcje nie działają na
swoich własnych kopiach, ale bezpośrednio na bazie danych.
“Optymizm” polega na założeniu, że żadnych konfliktów nie będzie. Ale konflikty są
tym niemniej wykrywane i w przypadku ich wykrycia, transakcje są zrywane, a baza
danych jest cofana do poprzedniego stanu.
Metody optymistyczne są bardzo nieskuteczne, jeżeli konfliktów jest dużo: praktycznie,
system staje i nie może poruszyć się ani o krok, bo co rusz, to konflikt...
Wykrycie konfliktów przy metodach optymistycznych jest oparte o podobną jak
wcześniej zasadę stempli czasowych.
Niemniej, metody optymistyczne nie są zbyt optymistyczne:
- mimo wielkich nadziei, są one rzadko stosowane
- jak się okazują, wymagają one również pewnej formy zamków i mogą prowadzić do
zakleszczeń.
Były nadzieje, że metody optymistyczne będą szczególnie przydatne w systemach
rozproszonych, gdzie zakładanie zamków jest bardzo kłopotliwe. Nie bardzo wiadomo
jednak, czy znalazły one efektywne zastosowanie. Ludzie są raczej pesymistami... 31
Ziarnistość mechanizmu transakcji
granularity
Pytanie: co ma być jednostką na którą zakłada się zamek, albo którą uważa się za
atomowy obiekt na którym będzie trzymać się stemple, kopiować, odtwarzać, itd.
Baza danych?
Relacja (tablica, ekstensja klasy)?
Krotka (obiekt)?
Element krotki (wartość atrybutu, pod-obiekt)?
A może fizyczna strona???
Grube ziarna (baza danych, relacja)
mały stopień współbieżności
Miałkie ziarna (np. element krotki)
duża pracochłonność zakładania zamków,
duże zapotrzebowanie na dodatkową
pamięć na zamki, przeciążenie sieci
Na dodatek, to trzeba zgrać z innymi mechanizmami, np. buforowaniem w RAM.
Testy dla systemów relacyjnych pokazują, że optymalną ziarnistość zapewnia
fizyczna strona.
Jest to wynik przykry (i tendencyjny), ponieważ uniemożliwia bardziej “inteligentne” mechanizmy
przetwarzania transakcji, takie, które ‘rozumieją” semantykę tego, co blokują (np. predicate32
locking).
Zmienna ziarnistość
variable granularity
Pomysł (Gray, 1977) polega na tym, aby obiekty do blokowania organizować hierarchicznie
i blokować w nich tyle, ile trzeba. Pomysł bardzo dobry dla obiektowych baz danych.
A blokuje
do aktualizacji
cały obiekt
A blokuje
do aktualizacji
kawałek obiektu
A blokuje
do czytania
cały obiekt
B blokuje
do czytania
kawałek obiektu
B blokuje
do aktualizacji
kawałek obiektu
Problem ze zmienną
ziarnistością polega na
tym, że (chyba) nikt nie
odważył się sprawdzić to
33
w powszechnej praktyce.
Typy awarii i reakcje na awarie
Zerwanie transakcji: z różnych powodów, wewnętrznych (np. czekaj-umieraj) lub
zewnętrznych. Transakcja może być powtarzana automatycznie lub (jeżeli to niemożliwe)
stracona. Program wywołujący transakcje powinien przewidywać sytuację, że transakcja
może być zerwana, wykryć to i ewentualnie powtórzyć.
Awaria systemu, ze stratą zawartości pamięci operacyjnej
Awaria nośników pamięci, ze stratą zawartości dysku.
Absolutna niezawodność
absolutna złożoność, nieskończony koszt
Czyli, niestety, nawet z transakcjami absolutna niezawodność jest niemożliwa.
Ale żyć się da, jeżeli awarie nie będą częściej niż np. raz na rok, więc nie jest źle...
W końcu zakłada się także ludzką interwencję, a ludzie na ogół jakoś sobie radzą z kłopotami...
Rozsądna niezawodność
mały wpływ na wydajność.
Transakcje rozsądnie podwyższają niezawodność, nie prowadząc do nadmiernych
obciążeń czasu wykonania ani dodatkowego zapotrzebowania na pamięć.
34
Odtwarzanie po awarii - środki, terminy
Back up
(bekap?)
Cykliczne przegrywanie zawartości bazy danych lub jej najważniejszych
fragmentów na inny nośnik (najczęściej taśmę magnetyczną). Cykl: co 30
min (banki), na koniec dnia (instytucje), co tydzień (uniwersytety), itp.
Recovery
(odtwarzanie)
Odtwarzanie (pół-automatyczne lub automatyczne) stanu bazy danych po
awarii na podstawie ostatniego backup-u i ew. logu.
Log
(dziennik)
Rollback
(cofanie)
Rejestracja wszystkich operacji zachodzących na bazie danych wraz ze
zmienianymi obiektami, z dokładnością do transakcji, które to robią
Cofanie operacji w bazie danych na podstawie logu, np. po zerwaniu
transakcji
Checkpoint
(czekpoint?)
Migawkowe zdjęcie stanu przetwarzania (trwałych i nietrwałych obiektów,
stanu sterowania, itd.) stosowane w niektórych systemach celem powrotu
do poprzedniego stanu, o ile programista/użytkownik tego sobie zażyczył.
Stosowane dla wykonania operacji undo.
Replication
(replikacja)
Zdublowanie informacji na fizycznie i geograficznie oddzielonych
nośnikach, celem zwiększenia niezawodności i zmniejszenia kosztów
35
transmisji.
Odtwarzanie po zerwaniu
Warunek atomowości transakcji wymaga, aby w przypadku zerwania wszelkie wykonane przez
nią czynności zostały odwrócone: baza danych ma wrócić do stanu sprzed transakcji.
Dwie strategie:
1. Transakcje działają na własnych kopiach, które podmieniają z oryginalnymi obiektami w
fazie commit. Wady: zwiększone zapotrzebowanie na pamięć, większa możliwość awarii w
fazie commit (bardzo niebezpieczne).
2. Transakcje działają bezpośrednio na bazie danych, ale w specjalnym pliku zwanym
dziennikiem (log) zapisują wszelkie operacje aktualizacyjne których dokonały, wraz z
obiektami przed i ew. po aktualizacji. W razie zerwania - baza danych jest odtwarzana
do poprzedniego stanu poprzez czytanie logu “od tyłu”.
relation LOG( trans_id, obiekt_id, operacja, stary_obiekt, nowy_obiekt)
Write ahead log: w dzienniku zapisywane są zmiany przed ich dokonaniem. W razie
awarii wiadomo, co było zrobione, czyli możliwe jest poprawne cofnięcie.
Czasami (SQL) stosuje się tryb oszczędny, w którym zmiany są zaznaczane w dzienniku, ale
nie są naniesione w bazie danych. Prowadzi to do tego, że transakcja “nie widzi” własnych
zmian, co jest sporą uciążliwością przy programowaniu i prowadzi do błędów.
36
Podstawowe algorytmy z zamkami
Dynamiczne dwufazowe blokowanie (2PL): transakcje ustanawiają zamki do czytania
(S) które następnie mogą podwyższyć do zamków do aktualizacji (X). Jeżeli zamek jest S,
to odrzucana jest próba założenia zamka X, jeżeli zamek jest X, to odrzucana jest
jakakolwiek próba założenia innego zamka. System prowadzi dziennik i graf czekania,
umożliwiając odtworzenie po zerwaniu i przeciwdziałając zakleszczeniu.
Czekasz-umieraj (wait-die) dwufazowy (WD): Tak jak dla 2PL, ale transakcja której
odmówiono dostępu ginie. Są odmiany tego algorytmu: z dwóch transakcji w konflikcie
ginie młodsza, ginie starsza, ginie ta, co się mniej narobiła, ginie ta, która jest mniej
ważna, itd.
Dynamiczne dwufazowe blokowanie bez podwyższania zamków: tak jak 2PL, ale nie
ma podwyższania zamków z S do X.
Wstępne żądanie zasobów (opis już był).
37
Komendy w SQL do przetwarzania
transakcji
Dowolne zdanie select, insert, update, delete, create rozpoczyna transakcję, o ile nie
była ona już przez tę transakcję rozpoczęta.
Transakcja trwa aż do do wydania komendy COMMIT (potwierdzającej), ABORT
lub ROLLBACK (zrywającej, cofającej). Transakcja może objąć dowolną liczbę zdań
select, insert, update, delete, create i innych.
Komenda SAVEPOINT <nazwa> oznacza zapamiętanie stanu pod określoną nazwą.
ABORT TO <nazwa> oznacza odtworzenie stanu.
SQL ma także inny kwiatek określany jako “isolations levels” (poziomy izolacji).
Idea jest słuszna: dla pewnych sytuacji warunek pełnej izolacji okazuje się zbyt mocny.
Np. byłoby prawie niemożliwe zrobienie raportu operacji na koniec dnia, jeżeli system
byłby w ciągłym ruchu, ponieważ zawsze jakieś dane byłyby zablokowane. Operacja by
“utykała” na każdym kroku, szef byłby mocno wkurzony, a biedny programista
oberwałby cięgi za nie swoje grzechy...
Osłabienie izolacji jest więc czasami konieczne, ale powinno to być traktowane
wyjątkowo, ze specjalnym statusem, ze specjalnymi środkami bezpieczeństwa.
Rozwiązanie SQL jest krytykowane jako dające programiście zbyt wiele “brudnych”
38
możliwości.
Zagnieżdżone transakcje
Czy mają sens?
C.J.Date argumentuje, że nie mają.
Reszta świata (wraz ze mną) uważa, że mają.
Powody: ułatwienie programowania, dostarczenie nowego mechanizmu abstrakcji.
Programista może kilka transakcji zamknąć w jedną większą bez zmiany tekstu programu.
Programista może większą transakcję rozbić na mniejsze bez zmiany koncepcji programu.
1
Dwie filozofie:
Zagnieżdżona transakcja jest potwierdzana wyłącznie dla swojej macierzystej
transakcji,
przez co aktualizacje zrobione przez pod-transakcję stają się widoczne dla innych
pod-transakcji. Zamki pod-transakcji są dziedziczone przez jej mamusię. Ostateczne
potwierdzenie pod-transakcji i zwolnienie zamków następuje po potwierdzeniu
transakcji stojącej najwyżej w hierarchii.
2
Każda pod-transakcja po potwierdzeniu bezpośrednio wprowadza zmiany do bazy
danych.
Zamki nie są dziedziczone (są zwalniane). Ale każda pod-transakcja posiada
bliźniaczą pod-transakcję kompensującą, która określa co robić, jeżeli mamusia nie
zostanie potwierdzona. Ta filozofia jest także określana jako saga.
39
Przykład zagnieżdżonej transakcji
Facet zgłasza się do biura podróży i chce jechać na wczasy na wyspy Hula Gula.
Z punktu widzenia biura podróży jest to jedna transakcja składająca się z wielu podtransakcji,
wykonywanych w większości równolegle:
Załatwienie formalności paszportowo-wizowych
Ubezpieczenie
Rezerwacja i kupienie biletu na pociąg na lotnisko.
Rezerwacja i wykupienie biletu na samolot na Hula Gula
Rezerwacja i zadatkowanie hotelu
Rezerwacja kosza na plaży
Rezerwacja i wykupienie biletu powrotnego na samolot z Hula Gula
Rezerwacja i wykupienie biletu powrotnego na pociąg
Opłata i umowa biura podróży z klientem
Jeżeli każdą z tych pod-transakcji można byłoby po prostu zerwać, wówczas
mielibyśmy zwyczajną zagnieżdżoną transakcję. Ale w życiu tak nie ma. Załóżmy, że
nie udało się zarezerwować kosza na plażę, a facet mówi: “Nie ma kosza, to nie jadę!”
W tej sytuacji powstaje saga: dla potwierdzonych pod-transakcji mogą być potrzebne
pod-transakcje kompensujące:
Zwrócenie biletu na pociąg (ze stratą)
Zwrócenie biletu na samolot (ze stratą)
Odwołanie rezerwacji hotelu (ze stratą)
....
40
Długie transakcje (transakcje
projektowe)
Jeżeli transakcje są bardzo długie wówczas klasyczne własności ACID są
niewygodne.
Załóżmy, że kilku autorów opracowuje ten sam projekt. Czy dopuszczalna
jest sytuacja, że koledzy nie mają możliwości obejrzenia jakiegoś fragmentu
projektu, ponieważ facet, który go opracowuje wykonał tam kilka zmian, nie
dokończył sprawy i poszedł na dłuższy urlop?
Długie transakcje wymagają osłabienia warunku izolacji lub jakiegoś innego pojęcia
szeregowalności. Pewnym rozwiązaniem są poziomy izolacji w SQL.
Pomimo wielu artykułów, w których mówi się jak ten problem jest ważny, nie
spotkałem ani jednego, który by jasno przestawił jakieś sensowne i nietrywialne
rozwiązanie.
Trywialne rozwiązanie jest oczywiste: specjalny tryb czytania obiektu, który omija
nałożone na niego zamki. Tzw. “kuchenne drzwi” (backdoor).
41
Podsumowanie
Transakcje są jednym z najprostszych i najbardziej skutecznych środków
zapewnienia bezpiecznego współbieżnego dostępu do wspólnej bazy danych.
Transakcje mogą być uważane za prosty i w miarę uniwersalny środek
synchronizacji równoległych procesów (bez semaforów, monitorów, kanałów i
innych trudnych pojęć). Synchronizacja polega na uniemożliwieniu jednoczesnej
aktualizacji tych samych zasobów.
Jednocześnie, transakcje maja zdolność przeciwdziałania losowym awariom.
Brak środków przetwarzania transakcji w takich systemach jak LotusNotes, MS
Office, czy też systemach przepływu prac (workflows) lub pracy grupowej jest
ogromnym utrapieniem, które (nie tylko w mojej opinii) w dużym stopniu
dyskwalifikuje te narzędzia.
Transakcje są szczególnie istotne w systemach rozproszonych baz danych lub w
systemach opartych o Internet lub Intranet.
Transakcje są na liście usług poziomych OMG CORBA, są też składnikiem
standardów ODMG, SQL3 i Workflow Management Coalition.
42