Transakcje w systemach obiektowych i nie tylko
Download
1 / 24

Transakcje w systemach obiektowych (i nie tylko) - PowerPoint PPT Presentation


  • 117 Views
  • Uploaded on

Transakcje w systemach obiektowych (i nie tylko). Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa. Po co transakcje? - Współbieżność. Spójność bazy danych, spójność procesów działających na bazie danych. Jeżeli wiele procesów działa jednocześnie na bazie danych: . Czas 1 2

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Transakcje w systemach obiektowych (i nie tylko)' - ura


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Transakcje w systemach obiektowych i nie tylko l.jpg
Transakcje w systemach obiektowych(i nie tylko)

Kazimierz Subieta

Instytut Podstaw Informatyki PAN,

Warszawa


Po co transakcje wsp bie no l.jpg
Po co transakcje? - Współbieżność

Spójność bazy danych, spójność procesów działających na bazie danych.

Jeżeli wiele procesów działa jednocześnie na bazie danych:

Czas

1

2

3

4

5

6

Proces A

Czyta X

X :=X+1

Zapisuje X

Proces B

Czyta X

X := X+1

Zapisuje X

Wartość XA

5

5

6

6

6

6

Wartość XB

5

5

6

6

6

Jeżeli te dwa procesy działalyby niezależnie, wynik byłby 7.

Działając równolegle i nie synchronizując swoich akcji jedna aktualizacja została zgubiona.

Inny przykład: mamy 4-ch autorów, którzy równolegle aktualizują 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:

umożliwienie zachowania spójności w takiej sytuacji bez potrzeby umawiania się.


Po co transakcje przeciwdzia anie awariom l.jpg
Po co transakcje? - Przeciwdziałanie awariom

Załóżmy, że mamy system bankowy, w którym następują operacje na kontach klientów

w sposób następujący:

Normalnie, aby klient

dostał swoje pieniądze,

tego rodzaju operacji

wykonuje się kilkadziesiąt.

Prawodpodobieństwo różnych

awarii jest spore.

1. Klient wczytuje karte 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

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, zaczyna się awantura,

dyrekcja tłumaczy, że nie odpowiada za elektrownię, klient ripostuje, że guzik go to obchodzi,...)

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


Transakcja jednostka dzia alno ci systemu l.jpg
Transakcja: jednostka działalności systemu

Nie mylić z procedurą! Transakcje i procedury są pojęciami ortogonalnymi. 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

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śc (durability) - po zakończeniu transakcji jej skutki sa na trwale zapamiętane

(na dysku) i nie mogą być odwrócone przez zdarzenia losowe (np. wyłączenie prądu)

A

C

I

D


Przyk adowa transakcja l.jpg
Przykładowa transakcja

Zacznij transakcję (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 wiekszy 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.


Kryterium poprawno ci transakcji l.jpg
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, jezeli jego koncowy 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 mialem 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ć).

Istnieja też opinie (Mohan) że teoria nie obejmuje ważnych przypadków takich jak usuwanie danych.

Problemy: znaleźć szeregowalny plan o minmalnym totalnym koszcie

znaleźć szeregowalny plan gdzie czas odpowiedzi nie jest dłuższy niż t,

....


Implementacja szeregowalno ci poprzez zamki l.jpg
Implementacja szeregowalności poprzez zamki

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.

Dzielony zamek (shared lock): inne transakcje mogą czytać, ale nie mogą modyfikować.

S

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

potwierdzenie

(commit)

Protokół 2PL

(two-phase locking)

koniec

start

zakładanie zamków

(nie ma zwalniania)

zwalnianie

zamków (nie

ma zakladania)

czas

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


Zakleszczenie l.jpg

Transakcja B

Transakcja A

Transakcja B

Transakcja A

Transakcja C

Transakcja C

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 zą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:

Zakleszczyły się dwie transakcje,

pozostałe działają normalnie:

W pętli zakleszczenia są 3 transakcje:


Walka z zakleszczeniem l.jpg
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).


Metody bez zakleszcze oparte na stemplach czasowych l.jpg
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.


Metody optymistyczne l.jpg
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 sa 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...


Ziarnisto mechanizmu transakcji l.jpg
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 pracochlonność 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 pokazują, że optymalną granulowość zapewnia fizyczna strona.

Jest to wynik przykry, ponieważ uniemożliwia bardziej “inteligentne” mechanizmy przetwarzania transakcji, takie, które ‘rozumieją” semantykę tego, co blokują (np. predicate locking).


Zmienna ziarnisto l.jpg

A blokuje

do aktualizacji

kawałek obiektu

B blokuje

do aktualizacji

kawałek obiektu

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 czytania

cały obiekt

B blokuje

do czytania

kawałek obiektu

Problem ze zmienną ziarnistością polega na tym, że (chyba) nikt nie

odważył się sprawdzić to w powszechnej praktyce.


Typy awarii i reakcje na awarie l.jpg
Typy awarii i reakcje na awarie

Zerwanie transakcji: z różnych powodów, wewnętrzych (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ęć.


Odtwarzanie po awarii rodki terminy l.jpg
Odtwarzanie po awarii - środki, terminy

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.

Back up

(bekap?)

Odtwarzanie (pół-automatyczne lub automatyczne) stanu bazy danych po awarii na podstawie ostatniego backup-u i ew. logu.

Recovery

(odtwarzanie)

Rejestracja wszystkich operacji zachodzących na bazie danych wraz ze zmienianymi obiektami, z dokładnościa do transakcji, które to robią

Log

(dziennik)

Cofanie operacji w bazie danych na podstawie logu, np. po zerwaniu transakcji

Rollback

(cofanie)

Migawkowe zdjęcie stanu przetwarzania (trwalych 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.

Checkpoint

(czekpoint?)

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

Replication

(replikacja)


Odtwarzanie po zerwaniu l.jpg
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.


Podstawowe algorytmy z zamkami l.jpg
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łozenia 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ł).


Komendy w sql do przetwarzania transakcji l.jpg
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.


Transakcje w odmg 2 0 l.jpg
Transakcje w ODMG 2.0

Transakcje nie zajmują sie obiektami ulotnymi.

Model transakcji jest tradycyjny, pesymistyczny (oparty na zamkach, locks).

Transakcja jest obiektem o następującym interfejsie:

interface Transaction {

void begin();

void commit();

void abort();

void checkpoint();

boolean active();

}

Wprowadzenie modyfikacji do bazy danych bez zwalniania zamków

Model rozproszonych transakcji jest taki sam jak model standardu OMG oraz ISO XA.

Model transakcji w ODMG obejmuje także wątki (threads)

Izolacji nie można osłabić.


Zagnie d one transakcje l.jpg
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 abstakcji.

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żdzona 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 sa 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


Przyk ad zagnie dzonej transakcji l.jpg
Przykład zagnieżdzonej 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ówszas 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ą)

....


2pc w systemach rozproszonych l.jpg
2PC w systemach rozproszonych

Two-phase commit

W systemach rozproszonych problemem jest faza potwierdzenia. Trwa długo, odbywa się przez zawodne łącza. Awaria w tej fazie może mieć straszne skutki, a jest bardzo prawdopodobna.

Program aplikacyjny

2

Mistrz

1

niewolnik

niewolnik

niewolnik

Dwu-fazowe potwierdzenie:

1. Niewolnicy wysyłają komunikaty “gotów “ do mistrza po przygotowaniu do aktualizacji

bd. Dane zmieniające stan lokalnych bd są dołączane do komunikatu.

2. Po zebraniu kompletu złoszeń od niewolników, mistrz dokonuje redystrybucji

nadesłanych danych na poszczególne komunikaty potwierdzenia, wysyłane do

poszczególnych niewolników. Niewolnicy nanoszą fizuczne zmiany.

Jeżeli jakikolwiek niewolnik nie zgłosi gotowości do potwierdzenia, mistrz wysyła komunikaty o zerwaniu transakcji.

Wada metody: zawieszenia systemu


D ugie transakcje transakcje projektowe l.jpg
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).


Podsumowanie l.jpg
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ą byc 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.