(dtp) xa oraz tx - Modele Inżynierii Teleinformatyki

(dtp) xa oraz tx - Modele Inżynierii Teleinformatyki

MAREK IWANIAK
WŁODZIMIERZ KHADZHYNOV
E-mail: [email protected], [email protected]
Wydział Elektroniki i Informatyki, Politechnika Koszalińska
Śniadeckich 2, 75-453 Koszalin
PRZEGLĄD DOSTĘPNYCH IMPLEMENTACJI
STANDARDÓW PRZETWARZANIA TRANSAKCJI ROZPROSZONYCH (DTP) XA ORAZ TX
Streszczenie: Celem artykułu jest usystematyzowanie wiedzy na temat dostępnych implementacji standardów realizacji transakcji rozproszonych. Kontekst
powstania tego artykułu oraz opis wcześniejszych prac badawczych zostały
przedstawione we wstępie. W punkcie drugim dokonano przypomnienia definicji transakcji oraz transakcji rozproszonej na podstawie protokołu dwufazowego zatwierdzania. W punkcie trzecim omówiono oparty na protokole
dwu-fazowego zatwierdzania model systemu rozproszonego przetwarzania
transakcji wprowadzony przez standard X/Open. Opisane zostały komponenty
oraz standaryzowane interfejsy XA oraz TX. W punkcie 4 przedstawiono wybrane implementacje wspomnianych standardów razem z opisem ich wymagań
oraz ograniczeń.
Słowa kluczowe: transakcje, bazy danych, SQL
1. Wstęp
W dotychczasowych badaniach zorientowanych na wykorzystanie sieci Petriego
w obszarze rozproszonych baz danych z wykorzystaniem zwykłych oraz Kolorowanych sieci Petriego przeprowadzaliśmy modelowanie protokołu 3PC (ang.
Three Phase Commit) z jednym uczestnikiem [1], protokołu 2PC (ang. Two
Phase Commit) z jednym uczestnikiem [2] oraz protokołu 2PC z wieloma
uczestnikami [3]. Badania były owocne oraz pozwoliły na wyciągnięcie szeregu
wniosków. Opracowana metodologia przedstawienia transakcji rozproszonej
82
Marek Iwaniak, Włodzimierz Khadzhynov
była czysto teoretyczna. Aby uzyskać jej dalszy rozwój należy ją zastosować do
odwzorowania działania rzeczywistego systemu rozproszonych baz danych.
Dwukrotnie badany przez nas protokół 2PC został wykorzystany w trakcie tworzenia technicznych standardów XA [4] oraz TX [5] przez konsorcjum X/Open
(obecnie część The Open Group). Projektując rzeczywisty system rozproszonej
bazy danych należy odpowiednio dobrać poszczególne komponenty spełniające
wspomniane standardy. W celu usystematyzowania wiedzy oraz wyłonienia
optymalnego dla naszych potrzeb zestawu komponentów konieczne stało się
przeprowadzenie przeglądu dostępnych implementacji w ramach rozwiązań
typu Open-Source,
W dalszej części niniejszego opracowania wyjaśniona zostanie istota transakcyjności oraz rozproszonego zatwierdzania transakcji z wykorzystaniem
protokołu dwufazowego zatwierdzania. Następnie przedstawiony zostanie architektura systemu przetwarzania transakcji rozproszonej za pomocą, którego
opisane zostały obowiązujące standardy publikowane przez The Open Group.
W dalszej części przedstawimy przegląd dostępnych implementacji tych standardów. W podsumowaniu przedstawimy wnioski z przeglądu oraz propozycję
zestawy komponentów.
2. Zatwierdzanie transakcji rozproszonych
Dane przechowywane w bazie danych są w pełni przydatne tylko wtedy gdy są
pewne i spójne. Każda zmiana wykonywana na danych w bazie powoduje
przejście do zupełnie nowego stanu bazy danych. Kolejne zmiany mogą występować równocześnie lub generować błędy. O zapewnienie poprawności i spójnego stanu bazy danych dba mechanizm transakcji. Właściwościami gwarantującymi poprawne przetwarzanie transakcji, są reguły ACID (ang. Atomicity,
Consistency, Isotation, Durability) czyli Atomowość, Spójność, Izolacja, Trwałość.
Na Rys. 1 przedstawiono protokół dwufazowego zatwierdzania w postaci
algorytmu. Przedstawiona reprezentacja została przygotowana na podstawie [7].
Nazwy stanów, komunikatów oraz zapisów do logów pozostały w oryginalnej angielskojęzycznej formie. Okręgi przedstawiają stany procesu koordynatora oraz uczestnika. Prostokąty przedstawiają operacje logowania otrzymanych
komunikatów i podjętych decyzji do dziennika systemowego. Strzałki opisują
przepływ komunikatów i sterowania.
Przegląd dostępnych implementacji standardów przetwarzania transakcji… 83
Rys. 1. Algorytm przedstawiający realizacje protokołu dwufazowego zatwierdzania
z jednym uczestnikiem
Samodzielny DBMS (ang. Database management system) czyli system zarządzania bazą danych ma zaimplementowanego TM (ang. transaction manager) zwanego menadżerem transakcji, dbającego o prawidłowe zarządzenia
stanem bazy danych (zagwarantowanie spełnienia reguł ACID) oraz komunikację z klientami.
W rozproszonej bazie danych pojawia się dodatkowa specjalistyczna komunikacja pomiędzy innymi menadżerami transakcji. Komunikacja ta zachodzi
pomiędzy menadżerem transakcji pełniącym rolę koordynatora, a pozostałymi
menadżerami transakcji pełniącymi rolę uczestników transakcji. Sposób komu-
84
Marek Iwaniak, Włodzimierz Khadzhynov
nikacji między koordynatorem, a uczestnikami definiuje określony protokół
rozproszonego zatwierdzania. Klasycznym przykładem takiego protokołu jest
zatwierdzanie dwu-fazowe (2 Phase Commit – 2PC). Protokół ten zgodnie
z nazwą realizuje dwie fazy: fazę głosowania i fazę zatwierdzania. Faza głosowania następuje po przesłaniu przez koordynatora zapytania o możliwość zatwierdzenia danej transakcji rozproszonej. Komunikaty zwrotne od uczestników
do koordynatora zawierają informacje o gotowości danego uczestnika do zatwierdzenia transakcji. Po zebraniu głosów od wszystkich uczestników następuje faza zatwierdzania lub wycofywania. Jeżeli koordynator otrzymał od wszystkich uczestników potwierdzenie gotowości, wysyła komunikat o globalnym
zatwierdzeniu transakcji. Jeżeli którykolwiek uczestnik zagłosuje przeciw zatwierdzeniu transakcji lub w ogóle nie prześle komunikatu (np. z powodu awarii), wówczas koordynator prześle komunikat o globalnym odrzuceniu tej transakcji. Podejmowanie decyzji o zatwierdzeniu tylko przy jednomyślnym
głosowaniu jest podstawowym sposobem zapewnienia atomowości transakcji
rozproszonej.
3. Architektura X/Open DTP
Publikacje The Open Group [6] posługują się modelem funkcjonalnym określanym jako „X/Open Distributed Transaction Processing architecture”. Model
zaprezentowany na Rys.2 przedstawia system rozproszony jako zestaw komponentów oraz interfejsów. Na Rys.2 wykorzystano pierwotne angielskie nazewnictwo. Po omówieniu znaczeń poszczególnych komponentów będziemy posługiwać się przyjętymi skrótami.
• AP (Application Program) reprezentuje aplikacje biznesową realizującą
funkcje pożądane przez użytkownika końcowego. Dany AP zawiera sekwencje operacji wykorzystujące różne źródła danych takie jak bazy danych lub inne. AP odpowiada za rozpoczęcie oraz zakończenie globalnej
transakcji oraz korzysta z zasobów w ramach transakcji. AP rozpoczyna
oraz kończy transakcje rozproszoną poprzez interfejs opisany standardem
TX. AP komunikuje się z każdym RM za pomocą dedykowanego interfejsu (jeżeli natywnym interfejsem danego zasobu jest język SQL, komunikacja AP-RM powinna odbywać się z wykorzystaniem SQL).
• RM (Resource Manager) zarządza pewnymi zasobami komputera, najczęściej jest to system DBMS, ale może nim być również np. system
plików.
Przegląd dostępnych implementacji standardów przetwarzania transakcji… 85
•
TM (Transaction Manager) na żądanie AP dba o realizację globalnej transakcji poprzez wygenerowanie unikalnego identyfikatora transakcji XID,
przekazanie go wszystkim RM. Nadzoruje atomowy przebieg transakcji
rozproszonej za pomocą dwu-fazowego protokołu zatwierdzania.
Rys. 2. Model architektury X/OPEN DTP
Schemat działania transakcji rozproszonej w kontekście architektury DTP wygląda następująco.
1. AP informuje TM o rozpoczęciu transakcji. TM generuje identyfikator
transakcji XID i go zwraca do AP.
2. TM informuje RM o rozpoczęciu rozproszonej transakcji o identyfikatorze XID.
3. Z wykorzystaniem XID AP łączy się z wszystkimi uczestniczących RM
za pomocą natywnego interfejsu wykonując zaplanowane operacje.
4. AP próbuje zatwierdzić transakcje zlecając TM przeprowadzenie procesu zatwierdzania.
5. TM rozpoczyna proces dwu-fazowego zatwierdzania. Zwraca informacje o powodzeniu operacji do AP.
86
Marek Iwaniak, Włodzimierz Khadzhynov
3.1. Standardy XA i TX
Standardy te opisują architekturę systemu DTP.
Standard XA specyfikuje wszystkie funkcje jakie TM może wykonywać podczas
komunikacji z RM oraz jakich wyników może się spodziewać. Wszystkie funkcje w relacji TM-RM rozpoczynają się przedrostka „xa_”. Przedstawia również
plik nagłówkowy <xa.h> z definicjami funkcji oraz struktur w języku C.
Standard TX specyfikuje wszystkie funkcje jakie AP może wykonać po połączeniu z TM. Wszystkie funkcje w relacji AP-TM rozpoczynają się przedrostka
„tx_”. Przedstawia również plik nagłówkowy <tx.h> z definicjami funkcji oraz
struktur w języku C oraz jego odpowiednik w języku COBOL. Dodatkowo stawiane są specjalne wymogi wobec poszczególnych komponentów:
• AP musi używać TM i przekazywać mu odpowiedzialność z przeprowadzenie transakcji rozproszonej.
• AP może mieć rozpoczętą tylko jedną transakcje rozproszoną.
• AP nie uczestniczy w procesie zatwierdzania
• AP w komunikacji z RM korzysta z natywnego interfejsu tak jakby TM
nie istniał. Do TM odwołuje się tylko wtedy gdy konieczne jest przeprowadzenie procesu rozproszonego zatwierdzania.
• RM musi móc rozpoznawać identyfikator XID oraz łączyć go operacjami wykonywanymi przez AP, aby zatwierdzić lub wycofać zmiany
w trakcie zatwierdzania transakcji nadzorowanej przez TM.
4. Dostępne implementacje
Poszukując komponentów do stworzenia rozproszonej bazy danych poszukiwania
musimy przeprowadzić dwóch kategoriach: menadżera transakcji (TM), menadżera zasobu (RM). Po za wykazem wymienić można komercyjne produkty takie
jak bazy danych Oracle czy Microsoft SqlServer, które jako zaawansowane narzędzia w zależności od konfiguracji mogą pełnić role zarówno TM jak i RM.
4.1. LIXA
Projekt LIXA (Libre XA) jest darmowym menadżerem transakcji (TM) rozwijanym jako oprogramowanie OpenSource. Projekt hostowany jest na sourceforge.org od 2009 roku, ostatnia aktualizacja kodu miała miejsce w 2012 roku.
Projekt można uruchomić jedynie na platformie UNIXowej, możliwość imple-
Przegląd dostępnych implementacji standardów przetwarzania transakcji… 87
mentacji na platformie Windows nie jest planowana oraz wymagałaby gruntownego przebudowania kodu aplikacji ze względu na wykorzystanie specyficznych dla UNIXowego jądra funkcji. Manager transakcji LIXA można wykorzystać w projekcie tworzonym w języku C, ale możliwe jest również
zaadaptowania kodu aplikacji do rozszerzenia języka PHP. Pozwala to na przygotowanie własnego AP jako skryptu PHP po uprzednim załadowaniu rozszerzenia LIXA oraz odpowiednich bibliotek pozywających na komunikacje z RM.
4.2. Bitronix
Bitronix jest manager transakcji napisanym w języku JAVA. Wspiera zarówno
proces zatwierdzania jak i proces odtwarzania transakcji rozproszonej. Możliwość komunikacji z RM ograniczony jest do takich, które posiadają implementacje sterownika opartą klasę javax.sql.XADataSource. Wspierane są zatem
następujące bazy danych: Apache Derby, IBM DB2, Informix, Microsoft SQL
Server, Oracle, PostgreSQL, Sybase ASE.
4.3. MySQL
MySQL od wersji 5.0 wspiera transakcje rozproszone zgodnie ze standardem
XA. Możliwość wykorzystanie zasobów bazy danych MySQL ograniczona jest
jednak tylko do mechanizmów przechowywania InnoDB. MySQL może pełnić
jedynie rolę RM. MySQL posiada pewne ograniczenia w tym jedno poważne,
przez które w przypadku zerwania połączenia lub wyłączenia serwera powoduje
wycofanie przygotowanej transakcji. W wersji 5.7 ograniczenie to nadal jest
wymieniane w dokumentacji.
4.4. PostgresSQL
Do PostgreSQL wprowadzono obsługę dwu-fazowego zatwierdzania w wersji 8.3
poprawiając w kolejnych wersjach zauważane zgłaszane błędy. W ramach projektu rozwijane jest rozszerzenie JDBC dedykowane dla tej bazy, a pełniące rolę
RM.
5. Podsumowanie
Analizując dostępne oprogramowanie możemy zauważyć, że rozbudowane
komercyjne programy dosyć szybko po opublikowaniu standardów zostały roz-
88
Marek Iwaniak, Włodzimierz Khadzhynov
budowane o niezbędne funkcje. Oprogramowanie Open-Source potrzebowało
co najmniej kilka lat więcej, aby zaadaptować nowe standardy. Ze względu na
możliwość wykorzystania TM LIXA jako rozszerzenia języka PHP zbudowanie
prototypowej aplikacji typu AP komunikującej się z kilkoma RM zapowiada się
obiecująco i nie powinno wymagać dużych nakładów pracy. Należy jednak
rozważyć przygotowanie systemu DTP z wykorzystaniem dojrzałych RM takich
jak PostgreSQL i Oracle XE, TM Bitronix oraz standardu JTA (Java Transaction API).
Literatura
1.
2.
3.
4.
5.
6.
7.
Iwaniak M., Khadzhynov W.: Wykorzystanie sieci Petriego do modelowania transakcji rozproszonych. Zeszyty naukowe STUDIA INFORMATICA
Volume 33, Number 2A (105), strony 255-270, Wydawnictwo Politechniki
Śląskiej, 2012
Iwaniak M., Khadzhynov W.: „Zastosowanie kolorowej sieci Petriego do
modelowania transakcji rozproszonej”, Modele inżynierii teleinformatyki
Tom 7, Politechnika Koszalińska, 2012
Iwaniak M., Khadzhynov W.: „Odwzorowanie działania protokołu dwu
fazowego zatwierdzania z wieloma uczestnikami za pomocą kolorowej sieci Petriego”, Zeszyty naukowe STUDIA INFORMATICA Volume 34,
Number 2A (111), strony 57-70 Wydawnictwo Politechniki Śląskiej, 2013
X/Open Company Ltd., Distributed Transaction Processing: The XA Specification, 1991, http://opengroup.org/
X/Open Company Ltd., Distributed Transaction Processing: The TX
(Transaction Demarcation) Specification, 1995, http://opengroup.org/
X/Open Company Ltd., Distributed Transaction Processing: Reference
Model, Version 3, 1996, http://opengroup.org/
Tamer Özsu M., Valduriez P.: Principles of Distributed Database Systems
III ed. Springer 2011
http://dev.mysql.com/doc/refman/5.7/en/xa.html
8.
9.
10. http://docs.codehaus.org/display/BTM
11. http://sourceforge.net/p/lixa/wiki/Home/treszczenie