we wczesnych dniach obliczeń nie było potrzeby przeprowadzania transakcji rozproszonych. Wraz ze wzrostem liczby aplikacji ważną kwestią staje się synchronizacja danych. Firmy sporo zapłaciły za utrzymanie zsynchronizowanych systemów pod względem przepływu danych. W rezultacie powstał 2-fazowy protokół commit zwany Xa (Extended Architecture). Protokół ten zapewnia właściwości KWASOPODOBNE dla globalnego przetwarzania transakcji. W tym artykule postaram się wyjaśnić szczegóły transakcji XA i wykorzystanie transakcji XA w Spring framework.
2 phase commit protocol jest atomowym protokołem zaangażowania dla systemów rozproszonych. Protokół ten, jak sama nazwa wskazuje, składa się z dwóch faz. Pierwszym z nich jest commit-Faza żądania, w której Menedżer transakcji koordynuje wszystkie zasoby transakcji, aby zatwierdzić lub przerwać. W fazie zatwierdzania Menedżer transakcji decyduje się na sfinalizowanie operacji, zatwierdzając lub przerywając zgodnie z głosami każdego Zasobu transakcji. Następnie przejdziemy do szczegółów implementacji protokołu 2PC.
* tutaj znajdziesz zasoby na temat interoperacyjności Java+. NET poprzez 2PC.
transakcje XA wymagają globalnego ID transakcji i lokalnego id transakcji(XID) dla każdego Zasobu XA. Każdy zasób XA jest zapisywany do Xa Managera metodą start(xid). Ta metoda informuje, że XA Resource jest zaangażowany w transakcję(bądź gotowy do operacji). Następnie pierwsza faza protokołu 2PC jest realizowana przez wywołanie metody prepare (xid). Ta metoda żąda OK lub ABORT vote z zasobu XA. Po otrzymaniu głosu z każdego Zasobu XA, Xa Manager decyduje się wykonać operację commit(xid), jeśli wszystkie zasoby XA wysyłają OK lub decyduje się wykonać rollback (xid), jeśli zasób XA wysyła ABORT. Wreszcie, metoda end(xid) jest wywoływana dla każdego Zasobu XA informującego, że transakcja została zakończona. Spójrz na postać, aby lepiej zrozumieć. Budując doświadczenie w implementacji transakcji XA, przyjrzymy się bliżej rodzajom awarii i możliwym rozwiązaniom.
awarie mogą wystąpić w dowolnym momencie z powodu utraty sieci, awarii maszyny i błędu administratora. W transakcji XA będziemy kategoryzować te awarie według faz, w których występują. Pierwsza faza awarii jest przed rozpoczęciem protokołu. Jest to prosta awaria, której system nie musi wycofywać ani wykonywać żadnej operacji. Po prostu nie wykonujemy operacji na ten konkretny moment. Drugi typ awarii może wystąpić na etapie przygotowania (commit-request), który może być łatwo obsługiwany przez wycofywanie za pomocą zasad timeout. Ostatni, ale nie najmniej ważny, to błędy fazy commit, które mogą wystąpić z powodu niekompletnych wycofań i wszelkich problemów w łańcuchu. We wszystkich powyższych sytuacjach Menedżer transakcji próbuje odzyskać problem. Następnie zobaczymy, jak transaction manager stara się przezwyciężyć awarie.
w celu odzyskiwania Menedżer transakcji wywołuje metodę odzyskiwania każdego Zasobu XA. Zasoby XA śledzą dzienniki i próbują odbudować swój najnowszy stan. Transaction Manager wzywa niezbędne operacje wycofania i misja została zakończona. Proces ten może wydawać się szczęśliwą ścieżką, ale istnieje wiele wyjątkowych sytuacji, w których logi są problematyczne, takie jak uszkodzenie. W tego rodzaju sytuacjach Menedżer transakcji stosuje pewne heurystyki, aby rozwiązać problem. Co więcej, proces odzyskiwania zależy od dzienników zapisu z wyprzedzeniem, w których zapisujesz dzienniki operacji przed złożeniem wniosku. W przypadku problemów z wydajnością dzienniki te są zapisywane we własnym formacie (Nie przy użyciu żadnej serializacji) i system powinien je lepiej wsadować, jeśli to możliwe. Następnie przechodzimy do części fun, która jest obsługą transakcji XA przez Spring framework.
Spring framework zapewnia rozbudowane środowisko do tworzenia aplikacji internetowych i samodzielnych. Podobnie jak inne dostępne narzędzia, transakcje XA są również obsługiwane przez Spring. Wsparcie to nie jest jednak implementacją natywną i wymaga hibernacji, kontenera sieciowego lub frameworka zapewniającego zarządzanie transakcjami XA. Spring ma JtaTransactionManager, który zapewnia narzędzia do zarządzania transakcjami i ukrywa szczegóły. W ten sposób możemy zarządzać transakcjami dla wielu źródeł danych, które są aktualizowane jednocześnie. Jeśli chodzi o zarządzanie transakcjami XA, obsługa hibernate i Web containers dla transakcji XA jest dobrze udokumentowana, nie trzeba o tym wspominać. Jednak praca z frameworkiem, który zapewnia transakcje XA, może być myląca. Dlatego będę kontynuował ten post, wprowadzając Bitronix Transaction Manager.
Bitronix można łatwo skonfigurować, zapewniając jednocześnie dobre wsparcie dla zarządzania transakcjami. Nie jest powszechnie stosowany w samodzielnych aplikacjach, ale postaram się podać konfigurację dla samodzielnej aplikacji w następujący sposób.
<bean factory-method="getConfiguration" class="bitronix.tm.TransactionManagerServices"> <!--Disabling Jmx avoids registering JMX Beans to any container--> <property name="disableJmx" value="true" /></bean><bean factory-method="getTransactionManager" class="bitronix.tm.TransactionManagerServices" depends-on="bitronixTMConfig" destroy-method="shutdown"/><bean class="org.springframework.transaction.jta.JtaTransactionManager"> <property name="transactionManager" ref="bitronixTM" /> <property name="userTransaction" ref="bitronixTM" /> <property name="allowCustomIsolationLevels" value="true" /></bean>
możemy teraz mieć wiele źródeł danych, które można skonfigurować w następujący sposób. Każde źródło danych powinno mieć właściwość uniqueName, która jest unikalna. Poniżej konfiguracja dotyczy Oracle, inne bazy danych mogą mieć różne konfiguracje. Wszelkie inne szczegóły można znaleźć na stronie internetowej Bitronix.
<bean class="bitronix.tm.resource.jdbc.PoolingDataSource" init-method="init" destroy-method="close"> <property name="uniqueName" value="xaDataSource" /> <property name="minPoolSize" value="1" /> <property name="maxPoolSize" value="4" /> <property name="testQuery" value="SELECT 1 FROM dual" /> <property name="driverProperties"> <props> <prop key="URL">jdbc:oracle:thin:@10.6.86.24:1521:test</prop> <prop key="user">test</prop> <prop key="password">test</prop> </props> </property> <property name="className" value="oracle.jdbc.xa.client.OracleXADataSource" /> <property name="allowLocalTransactions" value="true" /></bean>
podsumowując, staraliśmy się wyjaśnić, czym są transakcje XA, podstawowymi protokołami i integracją Bitronix Transaction Management Z Spring w samodzielnej aplikacji. W celu rozszerzenia, Xa Transactions zapewnia modyfikowanie różnych źródeł danych w tym samym czasie. Ponadto transakcje XA są obsługiwane przez kontenery sieciowe lub frameworki podobne do hibernacji. Niemniej jednak, być może będziemy musieli zintegrować zarządzanie transakcjami z samodzielną aplikacją, w której musimy skonfigurować Menedżera transakcji. W konsekwencji XA transaction zapewnia spójne operacje na wielu źródłach danych, a firmy z nich korzystają.
* notatki kuratora i dodatkowe zasoby