V počátcích výpočetní techniky, tam byl žádná potřeba pro distribuované transakce. Se zvyšujícím se počtem aplikací se synchronizace dat stává důležitou otázkou. Společnosti zaplatily hodně za údržbu synchronizovaných systémů z hlediska toku dat. V důsledku toho vznikl protokol 2 phase commit označovaný jako XA (eXtended Architecture). Tento protokol poskytuje vlastnosti podobné kyselinám pro globální zpracování transakcí. V tomto článku se pokusím vysvětlit podrobnosti o transakcích XA a použití transakcí XA v jarním rámci.
2 phase commit protocol je protokol atomového závazku pro distribuované systémy. Tento protokol, jak jeho název napovídá, se skládá ze dvou fází. První z nich je commit-request fáze, ve které transaction manager koordinuje všechny prostředky transakce odevzdat nebo zrušit. Ve fázi odevzdání se správce transakcí rozhodne dokončit operaci spácháním nebo přerušením podle hlasů zdroje každé transakce. Dále přejdeme k implementačním detailům protokolu 2PC.
* viz zde pro zdroje na Java+. Net Interoperability přes 2PC.
xa transakce potřebují globální ID transakce a místní ID transakce(xid) pro každý prostředek XA. Každý prostředek XA je zařazen do Xa Manager metodou start(xid). Tato metoda říká, že do transakce je zapojen prostředek XA (buďte připraveni na operace). Poté je první fáze protokolu 2PC realizována voláním metody prepare (xid). Tato metoda požaduje OK nebo přerušit hlasování ze zdroje XA. Po obdržení hlasovat z každé XA Zdrojů, XA Správce rozhodne provést commit(xid) operace, pokud všechny Zdroje XA odeslat OK nebo se rozhodne provést rollback(xid) pokud XA Resource posílá ABORT. Nakonec je metoda end(xid) volána pro každý prostředek XA, který říká, že transakce je dokončena. Podívejte se na obrázek, abyste lépe porozuměli. Když budujeme pozadí v implementaci transakcí XA, dále půjdeme hlouběji a uvidíme typy selhání a možná řešení.
k poruchám může dojít kdykoli kvůli ztrátě sítě, výpadku stroje a chybě Správce. V transakci XA tyto poruchy kategorizujeme podle fází, ke kterým dochází. První fáze selhání je před zahájením protokolu. Jedná se o jednoduché selhání, které systém nemusí vrátit zpět nebo jakýkoli druh operace. Prostě neděláme operaci pro tento konkrétní okamžik. Druhý typ selhání může nastat ve fázi prepare (commit-request), kterou lze snadno zpracovat vrácením zpět pomocí zásad časového limitu. V neposlední řadě je zavázat fáze selhání, které mohou nastat v důsledku neúplných vrácení zpět a jakýkoli problém v řetězci. Ve všech výše uvedených situacích se správce transakcí pokusí problém Obnovit. Dále uvidíme, jak se správce transakcí snaží překonat selhání.
pro obnovení volá správce transakcí metodu obnovení každého zdroje XA. Zdroje XA sledují protokoly a snaží se znovu vytvořit svůj nejnovější stav. Správce transakcí volá nezbytné operace vrácení zpět a mise je splněna. Tento proces se může zdát jako šťastná cesta, ale existuje mnoho výjimečných situací, kdy jsou protokoly problematické, jako by byly poškozeny. V těchto situacích, transakční manažer sleduje některé heuristiky k vyřešení problému. Proces obnovy navíc závisí na protokolech write-ahead, do kterých zapisujete protokoly operací před aplikací. Pro problémy s výkonem jsou tyto protokoly psány ve vlastním formátu (nepoužívají žádnou serializaci) a systém by je měl lépe dávkovat, pokud je to možné. Dále přejdeme k zábavné části, kterou je podpora transakcí XA Spring framework.
Spring framework poskytuje rozsáhlé prostředí pro vývoj webových a samostatných aplikací. Stejně jako ostatní nástroje, které poskytuje, transakce XA jsou také podporovány jarem. Tato podpora však není nativní implementací a vyžaduje hibernaci, webový kontejner nebo rámec, který poskytuje správu transakcí XA. Jaro má JtaTransactionManager, který poskytuje nástroje pro správu transakcí a skryje podrobnosti. Tímto způsobem můžeme mít správu transakcí pro více zdrojů dat, které jsou aktualizovány současně. Pokud jde o použití správy transakcí XA, hibernace a podpora webových kontejnerů pro transakce XA jsou dobře zdokumentovány, není třeba je zmiňovat. Práce s rámcem, který poskytuje transakce XA, však může být matoucí. Budu tedy pokračovat v tomto příspěvku zavedením Bitronix Transaction Manager.
Bitronix je snadno konfigurovatelný a zároveň poskytuje dobrou podporu pro správu transakcí. Není běžně používán v samostatných aplikacích, ale pokusím se dát konfiguraci pro samostatnou aplikaci následujícím způsobem.
<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>
Nyní můžeme mít více zdrojů dat, které lze konfigurovat následovně. Každý zdroj dat by měl mít vlastnost uniqueName, která je jedinečná. Níže je konfigurace pro Oracle, jiné databáze mohou mít různé konfigurace. Další podrobnosti najdete na webových stránkách 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>
abychom to shrnuli, pokusili jsme se vysvětlit, co jsou transakce XA, základní protokoly a integrace správy transakcí Bitronix s Spring v samostatné aplikaci. Chcete-li rozšířit, Xa transakce poskytuje úpravu různých zdrojů dat ve stejnou dobu. Kromě toho jsou transakce XA podporovány webovými kontejnery nebo hibernace jako rámce. Možná však budeme muset integrovat správu transakcí do samostatné aplikace, ve které musíme nakonfigurovat správce transakcí. V důsledku toho xa transaction poskytuje konzistentní operace na více zdrojích dat a společnosti je využívají.
* poznámky kurátora a další zdroje