SYSTEMY BAZ DANYCH

Część IV

Opracowanie : Dr Bożena
Śmiałkowska

Wprowadzenie do transakcji w bazach

danych

2

Definicja transakcji

3

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

4

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.

5

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.

6

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.

7

Trzeba uważać aby nie wpaść

w pewną pułapkę?

KLIENT 1

KLIENT 2

Wolne miejsce

Czy są wolne miejsca?

1

Czy są wolne miejsca?

1

Oferuje miejsce

1

Oferuje miejsce

1

Pytanie o kartę kredytową lub konto

1

Pytanie o kartę kredytową lub
konto

1

Podaje numer karty

Podaje numer konta

1

Autoryzacja

1

Autoryzacja

1

Przypisanie miejsca

1

Przypisanie miejsca

1

Obciążenie karty

1

Obciążenie karty

1

Zmniejszenie liczby wolnych miejsc

0

Zmniejszenie liczby wolnych
miejsc

-1

8

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ć???

9

Przykład transakcji

10

Przykład transakcji cd..

Każde wykonanie
programu
PRZELEW_PKO_WBK
powoduje utworzenie
nowej transakcji.

11

Przykład transakcji cd..

12

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

);

Takie programy mogą być proste lub dowolnie skomplikowane.
Z tego względu miara liczba transakcji/sekundę jest często
mało wiarygodna.

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

13

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

1
2
3
4
5
6

Proces B

Czyta X

X := X+1

Zapisuje X

Wartość X

A

5
5
6
6
6
6

Wartość X

B

5
5
6
6
6

Proces A

Czyta X

X :=X+1

Zapisuje X

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 na bazie
Danych. Można wówczas uzyskać spójność działania bez potrzeby umawiania się.

14

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ść.

15

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

C

I

D

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, 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 zapamiętane (na dysku) i nie mogą być
odwrócone przez zdarzenia losowe (np. wyłączenie prądu)

16

Własności transakcji cd..

17

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

18

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ąć.

19

Własności transakcji cd..

20

Własności transakcji cd..

21

Własności transakcji cd..

22

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,
....

23

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.

24

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.

25

Implementacja 2PL

(dwufazowe

blokowanie)

Zamek

(lock): jedna z transakcji rezerwuje sobie dostęp do obiektu.

Inne transakcje nie mają dostępu lub mają dostęp ograniczony.

X

Wyłączny zamek (exclusive lock): transakcja
zablokowuje jakikolwiek dostęp do obiektu dla innych
transakcji.

S

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

potwierdzenie
(commit)

koniec

czas

zakładanie zamków
(nie ma zwalniania)

zwalnianie
zamków (nie
ma zakładania)

Protokół 2PL

(two-phase locking)

Awarie są możliwe w obydwu fazach, ale faza commit jest szybka (milisekundy).

26

Implementacja 2PL…

27

Implementacja 2PL…

28

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:

Transakcja A

Transakcja B

Transakcja C

Transakcja A

Transakcja B

Transakcja C

W pętli zakleszczenia są 3 transakcje:

Zakleszczyły się dwie transakcje,
pozostałe działają normalnie:

29

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) oraz prowadzi do spadku efektywności
(sporo pracy idzie na marne).

30

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.

31

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...

32

Ziarnistość mechanizmu

transakcji

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.

granularity

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. predicate locking).

33

Zmienna ziarnistość

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.

variable granularity

A blokuje
do aktualizacji
cały obiekt

B blokuje
do aktualizacji
kawałek obiektu

A blokuje
do aktualizacji
kawałek obiektu

B blokuje
do czytania
kawałek obiektu

A blokuje
do czytania
cały obiekt

Problem ze
zmienną
ziarnistością
polega na tym, że
(chyba) nikt nie
odważył się
sprawdzić to w
powszechnej
praktyce.

34

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ęć.

35

Odtwarzanie po awarii - środki,

terminy

Back up
(bekap?)

Log
(dziennik)

Checkpoint
(czekpoint?)

Replication
(replikacja)

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)

Rollback
(cofanie)

Odtwarzanie (pół-automatyczne lub automatyczne) stanu
bazy danych po awarii na podstawie ostatniego backup-u i
ew. logu.
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

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.

Zdublowanie informacji na fizycznie i geograficznie
oddzielonych nośnikach, celem zwiększenia niezawodności i
zmniejszenia kosztów transmisji.

36

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”.

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.

relation LOG( trans_id, obiekt_id, operacja, stary_obiekt, nowy_obiekt)

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.

37

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ł).

38

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” możliwości.

39

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.

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.

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.

1

2

40

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ą)
....

41

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).

42

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.