în primele zile de calcul, nu a fost nevoie de tranzacții distribuite. Pe măsură ce numărul de aplicații a crescut, sincronizarea datelor devine o problemă importantă. Companiile au plătit mult pentru a menține sisteme sincronizate în ceea ce privește fluxul de date. Drept urmare, a apărut protocolul de comitere a fazei 2 denumit Xa(arhitectură extinsă). Acest protocol oferă proprietăți asemănătoare acidului pentru procesarea tranzacțiilor globale. De-a lungul acestui articol, voi încerca să explic detaliile tranzacțiilor XA și utilizarea tranzacțiilor XA în cadrul de primăvară.
protocolul de comitere a fazei 2 este un protocol de angajament atomic pentru sistemele distribuite. Acest protocol, după cum sugerează și numele său, constă din două faze. Prima este faza commit-request în care transaction manager coordonează toate resursele tranzacției pentru a comite sau abandona. În faza de comitere, managerul de tranzacții decide să finalizeze operațiunea prin comiterea sau întreruperea în funcție de voturile resursei fiecărei tranzacții. În continuare vom trece la detaliile de implementare a protocolului 2pc.
* vezi AICI pentru resurse pe Java+. Net interoperabilitate prin 2PC.
tranzacțiile XA necesită un ID de tranzacție global și un ID de tranzacție local(XID) pentru fiecare resursă XA. Fiecare resursă XA este înrolat la Xa Manager de start (xid) metoda. Această metodă spune că resursa XA este implicată în tranzacție(fiți gata pentru operațiuni). După aceea, prima fază a protocolului 2PC se realizează prin apelarea metodei prepare(xid). Această metodă solicită OK sau anulați votul din resursa XA. După ce a primit vot de la fiecare resursă XA, managerul xa decide să execute o operațiune commit(xid) dacă toate resursele XA trimit OK sau decide să execute o revenire (xid) dacă o resursă xa trimite avort. În cele din urmă, metoda end(xid) este apelată pentru fiecare resursă XA care spune că tranzacția este finalizată. Uită-te la figura pentru a înțelege mai bine. Pe măsură ce construim un fundal în implementarea tranzacțiilor XA, vom merge mai departe și vom vedea tipuri de eșecuri și soluții posibile.
eșecurile pot apărea în orice moment din cauza pierderii rețelei, a defectării mașinii și a unei greșeli de administrator. În tranzacția XA, vom clasifica aceste eșecuri în funcție de fazele în care apar. Prima fază de eșec este înainte de începerea protocolului. Acesta este un eșec simplu că sistemul nu trebuie să rollback sau orice fel de operațiune. Pur și simplu nu facem operația pentru acel moment. Al doilea tip de eșec poate apărea la faza de pregătire(commit-request), care poate fi ușor gestionată prin retrageri folosind Politici de expirare. Nu în ultimul rând este comite eșecuri de fază care pot apărea din cauza rollback-urilor incomplete și a oricărei probleme în lanț. În toate aceste situații de mai sus, transaction manager încearcă să recupereze problema. Vom vedea în continuare cum transaction manager încearcă să depășească eșecurile.
pentru recuperare, managerul de tranzacții solicită metoda de recuperare a fiecărei resurse XA. Resursele XA urmăresc jurnalele și încearcă să-și reconstruiască ultima condiție. Transaction Manager solicită operațiunile de rollback necesare și misiunea este îndeplinită. Acest proces poate părea a fi calea fericit, dar există o mulțime de situații excepționale în care jurnalele sunt problematice ca fiind corupt. În aceste tipuri de situații, transaction manager urmează unele euristici pentru a rezolva problema. Mai mult, procesul de recuperare depinde de jurnalele de scriere înainte în care scrieți jurnalele de operare înainte de a aplica. Pentru problemele de performanță, aceste jurnale sunt scrise în propriul format (nu utilizează nicio serializare) și sistemul ar trebui să le loteze mai bine dacă este posibil. În continuare mergem la partea distractivă, care este suportul pentru tranzacții XA de către Spring framework.
Spring framework oferă un mediu extins pentru a dezvolta aplicații web și de sine stătătoare. Ca și alte utilități pe care le oferă, tranzacțiile XA sunt, de asemenea, susținute de primăvară. Cu toate acestea, acest suport nu este o implementare nativă și necesită hibernare, container web sau un cadru care oferă gestionarea tranzacțiilor XA. Spring are JtaTransactionManager care oferă utilități de gestionare a tranzacțiilor și ascunde detaliile. În acest fel, putem avea managementul tranzacțiilor pentru mai multe surse de date care sunt actualizate simultan. Când vine vorba de a utiliza Xa Transaction Management, hibernate și containere web suport pentru tranzacțiile XA sunt bine documentate, nu trebuie să fie menționate. Cu toate acestea, lucrul cu un cadru care oferă tranzacții XA poate fi confuz. Astfel, voi continua acest post prin introducerea Bitronix Transaction Manager.
Bitronix este ușor de configurat oferind în același timp un suport bun pentru gestionarea tranzacțiilor. Acesta nu este frecvent utilizat în aplicații de sine stătătoare, dar voi încerca să dea de configurare pentru aplicarea stand-alone, după cum urmează.
<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>
acum putem avea mai multe surse de date care pot fi configurate după cum urmează. Fiecare sursă de date ar trebui să aibă o proprietate uniqueName care este unic. Configurația de mai jos este pentru Oracle, alte baze de date pot avea configurații diferite. Pentru orice alt detaliu, puteți verifica site-ul 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>
pentru a rezuma, am încercat să explicăm ce este tranzacțiile XA, protocoalele de bază și integrarea Bitronix Transaction Management cu Spring într-o aplicație autonomă. Pentru a extinde, Xa Transactions oferă modificarea diferitelor surse de date în același timp. În plus, tranzacțiile XA sunt acceptate de containere web sau hibernează ca cadre. Cu toate acestea, este posibil să fie nevoie să integrăm gestionarea tranzacțiilor într-o aplicație autonomă în care trebuie să configurăm transaction manager. În consecință, xa transaction oferă operațiuni consecvente pe mai multe surse de date, iar companiile le folosesc.
*notele curatorului și resursele suplimentare