Małgorzata Sikorska - Praktyczne porównanie mechanizmów 2PC i

Praktyczne porównanie mechanizmów 2PC i 3PC
dla rozproszonych baz danych
Małgorzata Sikorska
Wydział Inżynierii Mechanicznej i Informatyki
Kierunek Informatyka, Rok V
[email protected]
Streszczenie
Artykuł przedstawia porównanie podstawowych protokołów niepodzielnego zatwierdzania – 2PC oraz 3PC dla rozproszonych baz danych. Odgrywaja˛ one zasadnicza˛ rol˛e w przetwarzaniu transakcji rozproszonych. W celu praktycznego porównania tych protokołów zaprojektowano interfejsy realizujace
˛ mechanizmy 2PC i 3PC
w oparciu o model przetwarzania transakcyjnego DTP, a nast˛epnie zaimplementowano je w jednej z najpopularniejszych architektur rozproszenia wspomagajacych
˛
przetwarzanie transakcyjne – architekturze trójwarstwowej. W pracy skupiono si˛e
na przedstawieniu idei protokołów niepodzielnego zatwierdzania oraz ich oceny na
podstawie kryteriów, takich jak złożoność czasowa oraz złożoność pod wzgl˛edem
komunikatów, pozwalajacych
˛
na określenie ich wydajności.
1
Wprowadzenie
Przetwarzanie transakcyjne jest jednym z podstawowych elementów funkcjonalności systemów zarzadzania
˛
bazami danych. Jest ono niezb˛edne wsz˛edzie tam gdzie aplikacje wymagaja˛ jednoczesnego dost˛epu do danych, współdzielonych pomi˛edzy wiele aplikacji,
celem wykonania na nich operacji bazodanowych, stanowiacych
˛
koncepcyjnie logiczna˛
całość. Taki spójny logicznie zestaw operacji wykonywanych na bazie danych określany
jest terminem transakcja.
Najcz˛eściej transakcja obejmuje operacje na jednej bazie danych. W przypadku rozproszonej bazy danych (DDB – ang. Distributed Database), transakcja wykorzystuje dane
z wielu baz danych tzw. w˛ezłów systemu rozproszonego. Transakcje wykonujace
˛ operacje
na danych znajdujacych
˛
si˛e na wielu niezależnych serwerach baz danych, stanowiacych
˛
logiczna całość, określane sa˛ mianem transakcji rozproszonej (globalnej). Natomiast operacje składowe, czyli lokalne cz˛eści transakcji globalnej wykonywane na poszczególnych
w˛ezłach, sa˛ nazywane gał˛eziami transakcji (ang. transaction branch).
Zarówno w przypadku systemu scentralizowanego, jak i rozproszonego transakcja powinna odnosić si˛e do danych odtwarzalnych i być z założenia niepodzielna (ang. atomic).
W sytuacji, gdy operacje transakcji zostana˛ poprawnie zakończone, mówimy wtedy, że
transakcja zakończyła si˛e powodzeniem i jej skutki moga˛ zostać zatwierdzone w bazie
danych. W pozostałych przypadkach mówimy o niepowodzeniu transakcji i tym samym
1
skutki transakcji powinny być wycofane, a stan bazy danych powinien być przywrócony
do stanu sprzed rozpocz˛ecia transakcji. Aby zagwarantować powyższe własności każda
transakcja powinna spełniać postulaty zasady ACID (ang. atomictiy, consistency, isolation, durability), zaproponowane przez Haider’a i Reutera [3]:
• Atomowość (ang. atomicity) – określa reguł˛e „wszystko albo nic”, oznaczajac
˛ a,˛ że
zbiór operacji składowych transakcji musi być wykonany w całości albo wcale.
• Spójność (ang. consistency) – transakcja powinna przekształcać system z jednego
stanu spójnego w inny spójny stan.
• Izolacja (ang. isolation) – każda transakcja powinna być wykonywana niezależnie
od innych działajacych
˛
współbieżnie transakcji, przetwarzanych w tym samym środowisku. Skutki współbieżnego wykonania transakcji powinny być takie same, jak
wówczas gdyby wykonywano je w sposób szeregowy.
• Trwałość (ang. durability) – wyniki działania zatwierdzonych transakcji powinny
być zachowane w pami˛eci trwałej.
W systemie rozproszonym zagwarantowanie powyższych własności transakcji nie jest
zadaniem łatwym, dlatego też wprowadzono specjalne mechanizmy ułatwiajace
˛ przetwarzanie transakcji rozproszonych zapewniajace
˛ własności ACID. Sa˛ nimi protokoły niepodzielnego zatwierdzania (ang. atomic commitment protocols – ACP).
2
Zatwierdzanie rozproszone
Protokół niepodzielnego zatwierdzania jest algorytmem wykonywanym w celu niepodzielnego zatwierdzenia transakcji rozproszonej przez współpracujace
˛ w tym celu procesy. Każdy proces może oddać dokładnie jeden z dwóch możliwych głosów (ang. votes)
– Yes lub No, co pozwala na podj˛ecie wspólnej decyzji: Zatwierdzenie (ang. Commit) lub
Zaniechanie (ang. Abort) transakcji. ACP pozwala zadecydować, czy transakcje rozproszona˛ należy zatwierdzić, czy też nie [1]. Na podj˛ecie decyzji maja˛ wpływ nast˛epujace
˛
kwestie:
1. AC1 – Wszystkie procesy, które podejmuja˛ decyzje, podejmuja˛ ta˛ sama˛ decyzje.
2. AC2 – Procesy te nie moga˛ unieważnić swojej decyzji po tym jak już ja˛ podj˛eły.
3. AC3 – Decyzja o zatwierdzeniu może być podj˛eta tylko wtedy, gdy wszystkie procesy głosowały za zatwierdzeniem transakcji (oddały głos Yes).
4. AC4 – Jeżeli wszystkie procesy głosowały na Yes, wtedy decyzja˛ b˛edzie Zatwierdzenie.
5. AC5 – Powinno si˛e rozważyć wykonania algorytmu obejmujace
˛ różnego rodzaje
niepowodzenia takie jak awarie czy utraty komunikatów, do tolerowania których
algorytm został zaprojektowany. Jeżeli wszystkie zaistniałe awarie zostana˛ naprawione i nie wyst˛epuja˛ dostatecznie długo nowe awarie, wszystkie procesy podejma˛
w końcu decyzje.
2
3
Podstawowe protokoły niepodzielnego zatwierdzania
Najcz˛eściej stosowanym protokołem niepodzielnego zatwierdzania jest dwufazowy protokół zatwierdzania (ang. two-phase commit protocol), nazywany w skrócie protokołem
2PC [3]. Wykonanie protokołu 2PC rozpoczyna si˛e w momencie rozpocz˛ecia zatwierdzania transakcji rozproszonej przez proces zwany koordynatorem na zlecenie klienta. Składa
si˛e z dwóch faz, w pierwszej fazie koordynator decyduje, kiedy rozpoczać
˛ zatwierdzanie
transakcji rozproszonej. Jest to tzw. faza przygotowania (ang. prepare), każdy z uczestników transakcji przygotowuje si˛e do lokalnego zatwierdzenia transakcji rozproszonej.
Natomiast druga faza stanowi faz˛e rzeczywistego zatwierdzania (ang. commit) i rozpoczyna si˛e w momencie, gdy każdy z uczestników transakcji rozproszonej wyraził gotowość
do jej zatwierdzenia. Cały ten proces jest koordynowany przez zarzadc˛
˛ e transakcji (ang.
transaction manager), który może działać jako jeden z procesów systemu zarzadzania
˛
jednej z rozproszonych baz danych lub może być zewn˛etrznym modułem wbudowanym
w serwer aplikacji.
Protokół 2PC jest w wielu przypadkach protokołem blokujacym,
˛
ponieważ w wielu punktach wykonania tego protokołu procesy (sa˛ w stanie niepewności) oczekuja˛ na
komunikaty, które moga˛ dotrzeć z dużym opóźnieniem lub nigdy, na skutek awarii lub
innych okoliczności. W takich przypadkach procesy te moga˛ być czekać w nieskończoność, przez co sa˛ zablokowane. Na wypadek takich ewentualności stosuje si˛e w protokole
2PC mechanizm anulowania zadań po upływie przewidzianego czasu (ang. timeout). Pozwala to uniknać
˛ blokady procesów, gdyż oczekiwanie procesów jest przerywane przez
po określonym czasie, po którym proces musi podjać
˛ pewna˛ akcj˛e (ang. timeout action).
W przypadku protokołu 3PC mamy do czynienia z dodatkowa˛ faza˛ (pre-commit), w
której koordynator, po wyrażeniu gotowości przez każdego z uczestników transakcji do
jej zatwierdzenia, wysyła do nich komunikat informujacy
˛ o przygotowaniu si˛e do zatwierdzenia transakcji i tym samym opuszczaja˛ oni stan niepewności. Dopiero po otrzymaniu
koordynatora potwierdzenia otrzymania tego komunikatu przez wszystkich uczestników
transakcji, nast˛epuje jej rzeczywiste zatwierdzenie. Zapewnia to wi˛eksza˛ niezawodność
protokołu i odporność na awarie koordynatora [1].
4
Projekt i realizacja mechanizmów 2PC i 3PC
Istnieje wiele architektur rozproszenia, które wspomagaja˛ przetwarzanie transakcyjne.
Obecnie stosuje si˛e trójwarstwowa˛ architektur˛e rozproszona˛ oparta˛ na oprogramowaniu
pośredniczacym
˛
(ang. middleware), w której poszczególne w˛ezły porozumiewaja˛ si˛e za
pomoca˛ oprogramowania pośredniczacego,
˛
zakładajacy
˛ wspólny protokół komunikacyjny, przezroczysty dla użytkowników. W celu praktycznego porównania mechanizmy 2PC
i 3PC zostały zrealizowane w postaci komponentów oprogramowania middleware na serwerze aplikacji, w oparciu o j˛ezyk Java i funkcjonalności sterownika JDBC [12].
Ponieważ technologie oprogramowania komponentowego, tworza˛ środowisko, które
wymaga korzystania z ogólnie przyj˛etych modeli przetwarzania transakcyjnego, w niniejszej pracy aplikacja przetwarzajaca
˛ transakcje rozproszone zbudowana została w oparciu o model przetwarzania transakcji rozproszonych standardu X/Open (ang. Distributed
Transaction Processing Model – DTP) [11]. Specyfikuje on m.in. komponenty, współpracujace
˛ ze soba˛ celem realizacji transakcji rozproszonej – program aplikacyjny, za-
3
rzadca
˛
transakcji, zarzadcy
˛
zasobów. Określa także rodzaj interfejsów, jakie musza˛ być
dostarczone przez system transakcyjny w celu zapewnienia atomowego wykonania transakcji globalnej. Interfejsy pomi˛edzy komponentami programowymi, a zarzadc
˛ a˛ transakcji
(określony w specyfikacji X/Open jako interfejs TX) oraz pomi˛edzy zarzadca
˛
transakcji,
a zarzadc
˛ a˛ zasobów (zwany interfejsem XA). W niniejszej pracy funkcjonalność interfejsów TX i XA zastapiono
˛
omówionym poniżej interfejsami zawartymi w pakietach dtp,
transactions oraz tests. Poniżej omówione zostały komponenty programowe udost˛epniajace
˛ te interfejsy zgodnie z modelem DTP.
Komponent dtp.TransactionManager pełni funkcje zarzadcy
˛
transakcji, jest kluczowym elementem budowanej architektury. Dostarcza on przede wszystkim interfejsów niezb˛ednych do tworzenia transakcji, przypisania jej identyfikatora, rozpocz˛ecia i kontroli
protokołów niepodzielnego zatwierdzania.
• TID beginTransaction() – metoda pozwalajaca
˛ na rozpocz˛ecie transakcji rozproszonej oraz zwrócenie wynikowego identyfikatora transakcji.
• boolean commitTransaction(Transaction t) – metoda wykonujaca
˛ operacj˛e
zatwierdzenia transakcji rozproszonej t. W tym celu realizuje niepodzielny protokół zatwierdzania – ACP. Zwraca wartość TRUE, gdy transakcja globalna została
zatwierdzona, w przeciwnym wypadku zwraca FALSE.
• void rollbackTransaction(Transaction t) – metoda wykonujaca
˛ operacje
zaniechania transakcji.
• void joinResourceManager(ResourceManager participant) – dodanie nowego uczestnika (zarzadcy
˛
zasobów) transakcji rozproszonej (tzw. pozyskiwanie
zasobów). Pozwala na zapami˛etanie w spisie uczestników identyfikatora serwera
pełniacego
˛
rol˛e zarzadcy
˛
zasobów, który zarzadza
˛
zasobami wykorzystywanymi w
danej transakcji globalnej t.
Komponent dtp.ResorceManager, pełni rol˛e zarzadcy
˛
zasobów, który realizuje przydzielona˛ mu gałaź
˛ transakcji rozproszonej, bierze udział w protokole 2PC (3PC) celem niepodzielnego zatwierdzenia wszystkich gał˛ezi transakcji globalnej. Poniżej przestawione sa˛
interfejsy pozwalajace
˛ na uczestnictwo w protokole 2PC (3PC):
• Boolean Prepare(TID tid) – metoda wywoływana w pierwszej fazie protokołu
2PC (3PC). Wszyscy uczestnicy transakcji globalnej sa˛ poproszeni przez koordynatora (poprzez wywołane tej metody) o głosowanie za zatwierdzeniem tej transakcji
lub jej zaniechaniem. Metoda zwraca „głos” (ang. vote) uczestnika, czyli TRUE,
jeżeli uczestnik głosował za zatwierdzeniem transakcji, w przeciwnym wypadku
zwraca FALSE.
• void Commit(TID tid) – metoda zlecajaca
˛ poszczególnym uczestnikom transakcji (określonej identyfikatorem tid) zatwierdzenie ich lokalnych cz˛eści tej transakcji. Jest wywoływana w drugiej fazie protokołu 2PC lub odpowiednio w ostatniej
fazie protokołu 3PC, tylko w przypadku, gdy wszyscy uczestnicy transakcji głosowali za zatwierdzeniem transakcji globalnej.
• void Abort(TID tid) – metoda zlecajaca
˛ poszczególnym uczestnikom transakcji
(określonej identyfikatorem tid) zaniechanie ich lokalnych cz˛eści tej transakcji.
4
Wywoływana w drugiej fazie protokołu 2PC (3PC), w momencie, gdy chociaż jeden
z uczestników głosował za zaniechaniem transakcji lub faza ta nie powiodła si˛e
(ang. failed commit).
W przypadku protokołu 3PC dodatkowo jest udost˛epniony interfejs:
• boolean PreCommit(TID tid) – metoda wywoływana w drugiej fazie protokołu
3PC przez koordynatora po wykonaniu metody Prepare(). Jeżeli wszyscy uczestnicy głosowali YES, wysyła do nich komunikat PRE-COMMIT. Jest on informacja˛ dla
każdego z uczestników, że pozostali głosowali YES i tym samym opuszcza on stan
niepewności. Metoda zwraca potwierdzenie odebrania komunikatu, czyli TRUE, w
przeciwnym wypadku zwraca FALSE.
Każdy z omówionych wyżej komponentów zapewnia rejestracj˛e przebiegu transakcji rozproszonej w postaci wpisów w pliku rekonstrukcji znajdujacego
˛
si˛e w pami˛eci trwałej, co
pozwala na przeprowadzenie procesu rekonstrukcji w przypadku awarii serwera.
Komponent tests.Generator – klasa Java udost˛epniajaca
˛ interfejs, który realizuje funkcjonalność programu aplikacyjnego (ang. Application Program – AP) w modelu DTP.
Definiuje on transakcj˛e, określa jej granice oraz uzyskuje dost˛ep do zasobów, w celu wykonania na nich operacji .
5
Porównanie protokołów 2PC i 3PC
W tej cz˛eści przedstawione zostanie praktyczne porównanie protokołu 2PC z 3PC. Aby
dokonać realnej oceny każdego z nich przeprowadzono odpowiednie testy wydajnościowe. W tym celu wyznaczono ich złożoność pod wzgl˛edem komunikatów oraz czasowa.˛
Omówione w poprzednim rozdziale protokoły 2PC i 3PC zostały zaimplementowane w celach przetestowania ich wydajności w rzeczywistym środowisku. Przeprowadzone eksperymenty pozwalaja˛ oszacować koszty ponoszone przy wykorzystaniu każdego z
protokołów w aplikacjach trójwarstwowych (ang. three-tier applications). Obecnie najwi˛eksza wag˛e przy budowaniu aplikacji internetowych przykłada si˛e do wydajności, co
cz˛esto jest decydujacym
˛
czynnikiem wpływajacym
˛
na utrzymaniu starych i pozyskiwaniu
nowych klientów np. w systemach CRM. Dlatego też użyteczność protokołów 2PC oraz
3PC została określona na podstawie tego kryterium.
Mechanizm 2PC (3PC) został zaimplementowany w technologi J2EE na serwerze
aplikacji Apache Jakarta Tomcat 5.5.12 na maszynie z zainstalowana˛ maszyna˛ wirtualna˛
Java (JVM) w wersji 1.5.05. W celu przeprowadzenia testów pomini˛eto maszyny klientów
oraz implementacj˛e interakcji pomi˛edzy klientem (np. przegladarka
˛
WWW), a użytkownikiem, ponieważ celem niniejszej pracy jest praktyczne porównanie obydwu protokołów, a nie ich pełna implementacja. Rol˛e komponentu aplikacyjnego pełni komponent
JavaBean, który wykonuje operacje na zdalnych bazach danych poprzez oprogramowanie
middleware. Działa on na tej samej maszynie, co serwer aplikacji. Funkcj˛e zdalnych baz
danych pełnia˛ maszyny z zainstalowanym serwerem baz danych MySQLServer 5.0 oraz
PostgreSQL 8.0. Komunikacja z warstwa˛ danych si˛e z nimi za pomoca˛ sterownika JDBC
w wersji 2.0. Wszystkie maszyny sa˛ fizycznie rozmieszczone w sieci lokalnej połaczone
˛
siecia˛ Ethernet.
W pierwszym eksperymencie dokonano symulacji wymiany komunikatów pomi˛edzy
poszczególnymi procesami, bioracymi
˛
udział w protokole niepodzielnego zatwierdzania,
5
w celu porównania złożoności pod wzgl˛edem komunikatów protokołu 2PC z 3PC. Zakładamy, że złożoność pod wzgl˛edem komunikatów jest mierzona na podstawie liczby
komunikatów użytych w protokole. W przeprowadzonym eksperymencie nie bierzemy
pod uwag˛e długości tych komunikatów, ponieważ sa˛ one na tyle krótkie, że maja˛ wpływu
na ta˛ złożoność.
Przebieg eksperymentu był nast˛epujacy:
˛ wygenerowano zbiór żadań
˛
req do koordynatora o zatwierdzenie transakcji rozproszonej. Niech n oznacza liczb˛e uczestników transakcji rozproszonej, tak wi˛ec łaczna
˛
liczba procesów (z koordynatorem) wynosi (n + 1).
Rozpocz˛eto symulacj˛e z parametrem n = 2. Dla każdego późniejszego pojedynczego wywołania procedury testujacej
˛ wartość parametru została zwi˛ekszana o 1. Podczas trwania eksperymentu komunikacja pomi˛edzy procesami przebiegała w nast˛epujacy
˛ sposób:
klient składa żadanie
˛
do serwera aplikacji warstwy pośredniej. Nast˛epnie oprogramowanie warstwy pośredniej przetwarza to żadanie
˛
poprzez wykonanie transakcji na odpowiednim serwerze bazy danych. Rzeczywista manipulacja na zasobach udost˛epnionych przez
rozproszona˛ baz˛e danych jest taka sama w obydwu przypadkach. Przy realizacji protokołu niepodzielnego zatwierdzania przez oprogramowanie warstwy pośredniej w przypadku
protokołu 3PC wymagana jest wi˛eksza liczba komunikatów niezb˛ednych do zatwierdzenia transakcji rozproszonej. Po tym procesie, middleware zawraca wynik wykonania operacji SQL do klienta.
Analizujac
˛ wyniki powyższego eksperymentu można wywnioskować, że w przypadku
pojedynczego wykonania protokołu 2PC, w każdej rundzie jego wykonania, wysłane zostaje n komunikatów. Zatem przy braku awarii, protokół używa łacznie
˛
3n komunikatów.
Jest to nieduża liczba w porównaniu z protokołem 3PC, w przypadku którego przeprowadzone badania wykazały, że wymaga on łacznie
˛
około 5n komunikatów. Eksperyment
wykazał, że koszt liczony w komunikatach jest wprost proporcjonalny do 3n dla protokołu
2PC, natomiast dla protokołu 3PC jest on wprost proporcjonalny do 5n. Dla pojedynczego
wywołania jest to niewielka różnica, natomiast w przypadku dużej liczby żadań
˛
zatwierdzenia kolejnych transakcji rozproszonych wykonywanych na wielu serwerach, staje si˛e
ona istotnym parametrem wpływajacym
˛
na wydajności każdego z protokołów.
Celem zmierzenia złożoności czasowej protokołu 2PC i 3PC wyliczona została liczba obiegów wymiany komunikatów (ang. message exchange round) potrzebnych przez
działajace
˛ serwery do podj˛ecia decyzji w najgorszym przypadku. Przez poj˛ecie obiegu
rozumiemy maksymalny czas potrzebny komunikatowi na dotarcie do miejsca przeznaczenia [1]. W przeprowadzonych eksperymentach uwzgl˛edniono również czas potrzebny
na przetworzenie komunikatów oraz czas pochłaniany przez dost˛ep do pami˛eci trwałej w
celu zapisania, badź
˛ odczytania informacji zapisanych w plikach rekonstrukcji.
Maksymalna liczba obiegów komunikatów (w protokole 2PC) potrzebna działajacym
˛
procesom do podj˛ecia decyzji wynosi trzy obiegi: (1) koordynator rozgłasza komunikat
VOTE-REQs, (2) uczestnicy odpowiadaja˛ poprzez głosowanie, (3) koordynator rozgłasza
decyzj˛e. Ma to miejsce podczas bezawaryjnego wykonania protokołu 2PC, w sytuacji,
gdy transakcja globalna zostaje zatwierdzona.
Poszczególne czasy opóźnienia dla protokołu 2PC przedstawiono w tabeli 1, gdzie:
• tt – całkowity czas opóźnienia, na który jest suma˛ opóźnień spowodowanych przez
obiegi, dost˛epy do pami˛eci trwałej oraz rozgłaszanie komunikatów:
• tr – oznacza czas rozgłaszania komunikatu VOTE-REQs (1);
6
• tg – oznacza czas potrzebny na głosowanie (2).
• td – czas potrzebny na rozgłoszenie decyzji (3).
Tab. 1: Złożoność czasowa protokołu 2PC.
n
tr
tg
td
tt
1 14 10 13
38
2 31 16 28
75
3 46 22 45 113
4 63 34 62 159
5 76 44 78 198
Złożoność czasowa protokołu 3PC w przypadku braku awarii sprowadza si˛e od co najwyżej pi˛eciu rund komunikatów: (1) rozgłoszenie VOTE-REQs, (2) dostarczenie głosów,
(3) rozprowadzenie PRE-COMMITS, (4) potwierdzenie PRE-COMMIT, (5) rozprowadzenie
COMMIT. Również ma to miejsce przy bezwaryjnym wykonaniu protokołu 3PC przy zatwierdzeniu transakcji globalnej.
Poszczególne czasy opóźnienia dla protokołu 3PC przedstawiono w tabeli 2, gdzie:
• tt – całkowity czas opóźnienia.
• tr – oznacza czas rozgłaszania komunikatu VOTE-REQs (1);
• tg – oznacza czas potrzebny na głosowanie (2).
• t p – przeprowadzenie dodatkowej fazy pre-commit (3), (4).
• td – czas potrzebny na rozgłoszenie decyzji (5).
Tab. 2: Złożoność czasowa protokołu 3PC.
n
tr
tg
tp
td
tt
1 16
8 11 17
54
2 29 17 24 31 101
3 48 22 35 49 154
4 64 35 47 67 213
5 78 48 64 83 273
Porównujac
˛ wyniki eksperymentów z tabeli 1 z tabela˛ 2 łatwo wywnioskować, że każdy
dodatkowy obieg komunikatów opóźnia proces zatwierdzania transakcji rozproszonej. W
przypadku protokołu 3PC opóźnienie to jest spowodowane przez dwa dodatkowe obiegi
komunikatów (3), (4).
Im wi˛eksza liczba wezłów bioracych
˛
udział w transakcji, tym wi˛ekszy jest koszt wykonania dodatkowych obiegów komunikatów oraz dost˛epów do pami˛eci trwałej, co skutkuje znacznym opóźnieniem procesu przetwarzania transakcji. Dodatkowy czas musi zostać poświ˛econy na zapewnienie niepodzielności zatwierdzania transakcji rozproszonej.
W przypadku protkołu 2PC czas ten waha si˛e od 38ms dla n = 1 do 198ms dla n = 5. Dla
protokołu 3PC sa˛ to 54ms dla n = 1 do 273ms dla n = 5. Jak widać różnica w czasie opóźnienia spowodawanym przez protokół 3PC, w prównaniu z protokołem 2PC, zwi˛eksza si˛e
wraz z liczba˛ uczestników.
7
6
Podsumowanie
W pracy przedstawione wst˛epne wyniki porównania protokołu 2PC z 3PC. Przeprowadzone eksperymenty wykazały, że protokół 3PC powoduje wi˛eksze narzuty na wydajność
przetwarzania transakcji rozproszonej niż protokół 2PC. W porównaniu z protokołem
2PC wymaga on wi˛ekszej liczby komunikatów do przeprowadzenia procesu zatwierdzania roszproszonego, która rośnie wraz z liczba˛ uczestników transakcji.
Wraz ze wzrostem liczby komunikatów rośnie również czas potrzebny na ich rozsyłanie i przetworzenie. Nie należy również zapominać o czasie pochłanianym przez dost˛ep
do informacji zapisanych w dziennikach transakcji w pami˛eci trwałej. Takie przymusowe
dost˛epy w pami˛eci trwałej sa˛ dosyć czasochłonne. Koszty te moga˛ spowodować, że przetwarzanie zatwierdzania transakcji rozproszonej może przyczynić si˛e do wzrostu czasu
przetwarzania całej transakcji. Ponieważ w protokołe 2PC liczba i złożoność komunikatów jest o mniejsza, jego wydajność jest wi˛eksza.
Literatura
[1] P.A. Bernstein, V. Hadzilacos, N. Goodman, Concurrency control and recovery in
database systems, ADDISON-WESLEY PUBLISHING COMPANY, 1987.
[2] L. Banachowski, K. Stencel, Bazy danych. Projektowanie aplikacji na serwerze, Wydawnictwo Exit , 2001.
[3] G.Coulouris, J. Dollimore, T. Kindberg, Systemy rozproszone – podstawy i projektowanie, Wydawnictwo Naukowo–Techniczne, 1998.
[4] H. Garcia-Molina, J.D. Ullman, J. Widom, Implementacja systemów baz danych,
Wydawnictwo Naukowo–Techniczne, 2003.
[5] R. Elmasri S.B. Navath, Wprowadzenie do systemów baz danych, Helion, 2005.
[6] S. Allamaraju, Nuts and Bolts of Transaction Processing, 1999.
[7] M. Stróżańki, Systemy rozproszone – Konsekwencje wyboru architektury systemu,
1999.
[8] M. Wojciechowski, M. Zakrzewicz, Obsługa transakcji rozproszonych w j˛ezyku Java, 2003.
[9] S. Frolund, S. R. Guerraoui, Exactly-Once Transactions, HP Software Technology
Laboratory,1999.
[10] R. Gupta, J. Harista, K. Ramamritham, Revisiting Commit Processing In Distributed
Database Systems, University of Utah Mathematics Department Software, 1997.
[11] Distributed Transaction Processing: The XA Specification, www.opengroup.org/,
1991.
[12] JDBC Technology, http://java.sun.com/products/jdbc.
8