MAREK IWANIAK WŁODZIMIERZ KHADZHYNOV E-mail: marek.iwaniak@tu.koszalin.pl, hadginov@ie.tu.koszalin.pl Wydział Elektroniki i Informatyki, Politechnika Koszalińska Śniadeckich 2, 75-453 Koszalin PRZEGLĄD DOSTĘPNYCH IMPLEMENTACJI STANDARDÓW PRZETWARZANIA TRANS- AKCJI 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 3.1. Standardy XA i TX Marek Iwaniak, Włodzimierz Khadzhynov 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. 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 2. Iwaniak M., Khadzhynov W.: Zastosowanie kolorowej sieci Petriego do modelowania transakcji rozproszonej, Modele inżynierii teleinformatyki Tom 7, Politechnika Koszalińska, 2012 3. 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 4. X/Open Company Ltd., Distributed Transaction Processing: The XA Specification, 1991, http://opengroup.org/ 5. X/Open Company Ltd., Distributed Transaction Processing: The TX (Transaction Demarcation) Specification, 1995, http://opengroup.org/ 6. X/Open Company Ltd., Distributed Transaction Processing: Reference Model, Version 3, 1996, http://opengroup.org/ 7. Tamer Özsu M., Valduriez P.: Principles of Distributed Database Systems III ed. Springer 2011 8. http://dev.mysql.com/doc/refman/5.7/en/xa.html 9. 10. http://docs.codehaus.org/display/btm 11. http://sourceforge.net/p/lixa/wiki/home/treszczenie