En guide til Atomikos

1. Introduktion

Atomikos er et transaktionsbibliotek til Java-applikationer. I denne vejledning forstår vi, hvorfor og hvordan man bruger Atomikos.

I processen gennemgår vi også det grundlæggende i transaktioner, og hvorfor vi har brug for dem.

Derefter opretter vi en simpel applikation med transaktioner, der udnytter forskellige API'er fra Atomikos.

2. Forstå det grundlæggende

Før vi diskuterer Atomikos, lad os forstå, hvad nøjagtige transaktioner er, og et par begreber relateret til dem. Enkelt sagt, en transaktion er en logisk enhed af arbejde, hvis effekt er synlig uden for transaktionen, enten i sin helhed eller slet ikke.

Lad os tage et eksempel for at forstå dette bedre. En typisk detailapplikation reserverer beholdningen og afgiver derefter en ordre:

Her vil vi gerne have, at disse to operationer enten sker sammen eller slet ikke sker. Vi kan opnå dette ved at indpakke disse operationer i en enkelt transaktion.

2.1. Lokal vs. distribueret transaktion

En transaktion kan involvere flere uafhængige operationer. Disse operationer kan udføre på den samme ressource eller forskellige ressourcer. Vi refererer til de deltagende komponenter i en transaktion som en database som en ressource her.

Transaktioner inden for en enkelt ressource er kendt lokal transaktion, mens de, der gyder på tværs af flere ressourcer, er kendt som den distribuerede transaktion:

Her kan lager og ordrer være to tabeller i den samme database, eller de kan være to forskellige databaser - muligvis kører på forskellige maskiner helt.

2.2. XA Specification og Java Transaction API

XA henviser til eXtended Architecture, som er en specifikation til distribution af distribueret transaktion. Det Målet med XA er at levere atomicitet i globale transaktioner, der involverer heterogene komponenter.

XA-specifikation giver integritet gennem en protokol, der kaldes en to-faset forpligtelse. To-fasetilsagn er en udbredt distribueret algoritme til at lette beslutningen om at begå eller tilbageføre en distribueret transaktion.

Java Transaction API (JTA) er en Java Enterprise Edition API udviklet under Java Community Process. Det gør det muligt for Java-applikationer og applikationsservere at udføre distribuerede transaktioner på tværs af XA-ressourcer.

JTA er modelleret omkring XA-arkitektur og udnytter to-faset forpligtelse. JTA specificerer standard Java-grænseflader mellem en transaktionsadministrator og de andre parter i en distribueret transaktion.

3. Introduktion til Atomikos

Nu hvor vi har gennemgået det grundlæggende i transaktioner, er vi klar til at lære Atomikos. I dette afsnit vil vi forstå, hvad præcis Atomikos er, og hvordan det relaterer til begreber som XA og JTA. Vi forstår også Atomikos arkitektur og gennemgår dets produkttilbud.

3.1. Hvad er Atomikos

Som vi har set leverer JTA grænseflader i Java til opbygning af applikationer med distribuerede transaktioner. Nu er JTA bare en specifikation og tilbyder ikke nogen implementering. For os for at køre en applikation, hvor vi udnytter JTA, har vi brug for en implementering af JTA. En sådan implementering kaldes en transaktionsmanager.

Typisk leverer applikationsserveren en standardimplementering af transaktionsadministratoren. For eksempel i tilfælde af Enterprise Java Beans (EJB) administrerer EJB-containere transaktionsadfærd uden nogen eksplicit intervention fra applikationsudviklere. I mange tilfælde er dette muligvis ikke ideelt, og vi har muligvis brug for direkte kontrol over transaktionen uafhængigt af applikationsserveren.

Atomikos er en letvægts transaktionsmanager til Java der gør det muligt for applikationer, der bruger distribuerede transaktioner, at være selvstændige. I det væsentlige behøver vores applikation ikke at stole på en tungvægtskomponent som en applikationsserver til transaktioner. Dette bringer konceptet med distribuerede transaktioner tættere på en cloud-native arkitektur.

3.2. Atomikos Arkitektur

Atomikos er primært bygget som en JTA-transaktionschef og dermed implementerer XA-arkitektur med en to-faset kommitteringsprotokol. Lad os se en arkitektur på højt niveau med Atomikos:

Her letter Atomikos en to-fase-forpligtelsesbaseret transaktion, der spænder over en database og en meddelelseskø.

3.3. Atomikos produkttilbud

Atomikos er en distribueret transaktionsmanager, der tilbyder flere funktioner end hvad JTA / XA kræver. Det har et open source-produkt og et meget mere omfattende kommercielt tilbud:

  • Transactions Essentials: Atomikos ' open source-produkt, der leverer JTA / XA-transaktionshåndtering til Java-applikationer arbejde med databaser og meddelelseskøer. Dette er mest nyttigt til test- og evalueringsformål.
  • ExtremeTransactions: den kommercielt tilbud af Atomikos, der tilbyder distribuerede transaktioner på tværs af sammensatte applikationer, inklusive REST-tjenester bortset fra databaser og meddelelseskøer. Dette er nyttigt til at opbygge applikationer, der udfører Extreme Transaction Processing (XTP).

I denne vejledning bruger vi TransactionsEssentials-biblioteket til at opbygge og demonstrere funktionerne i Atomikos.

4. Opsætning af Atomikos

Som vi har set tidligere, er et af højdepunkterne i Atomikos det det er en integreret transaktionstjeneste. Hvad dette betyder er, at vi kan køre det i samme JVM som vores applikation. Således er opsætning af Atomikos ret ligetil.

4.1. Afhængigheder

Først skal vi indstille afhængighederne. Her er alt, hvad vi skal gøre, at erklære afhængighederne i vores Maven pom.xml fil:

 com.atomikos-transaktioner-jdbc 5.0.6 com.atomikos-transaktioner-jms 5.0.6 

Vi bruger Atomikos-afhængigheder til JDBC og JMS i dette tilfælde, men lignende afhængigheder er tilgængelige på Maven Central for andre ressourcer om XA-klage.

4.2. Konfigurationer

Atomikos leverer flere konfigurationsparametre med fornuftige standardindstillinger for hver af dem. Den nemmeste måde at tilsidesætte disse parametre på er give en transaktioner. ejendomme fil i klassestien. Vi kan tilføje flere parametre til initialisering og drift af transaktionstjenesten. Lad os se en simpel konfiguration til at tilsidesætte den mappe, hvor logfiler oprettes:

com.atomikos.icatch.file = sti til din fil

Tilsvarende er der andre parametre, som vi kan bruge til at kontrollere timeout for transaktioner, indstille unikke navne til vores applikation eller definere nedlukningsadfærd.

4.3. Databaser

I vores vejledning bygger vi en simpel detailapplikation, som den vi beskrev tidligere, som reserverer beholdning og derefter afgiver en ordre. Vi bruger en relationsdatabase for enkelhedens skyld. Desuden bruger vi flere databaser til at demonstrere distribuerede transaktioner. Imidlertid, dette kan meget godt udvides til andre ressourcer om XA-klage som meddelelseskøer og emner.

Vores lagerdatabase vil have en simpel tabel til at være vært for produktbeholdninger:

OPRET TABELOPGANG (produktId VARCHAR PRIMÆR NØGLE, balance INT);

Og vores ordredatabase vil have en simpel tabel til at være vært for placerede ordrer:

OPRET TABELORDRER (orderId VARCHAR PRIMÆR NØGLE, productId VARCHAR, mængde INT IKKE NULL CHECK (mængde <= 5));

Dette er et meget grundlæggende databaseskema og kun nyttigt til demonstrationen. Det er dog vigtigt at bemærke, at vores skemabegrænsning ikke tillader ordre med en produktmængde på mere end fem.

5. Arbejde med Atomikos

Nu er vi klar til at bruge et af Atomikos-bibliotekerne til at opbygge vores applikation med distribuerede transaktioner. I de følgende underafsnit bruger vi de indbyggede Atomikos ressource adaptere til at oprette forbindelse til vores back-end databasesystemer. Dette er den hurtigste og nemmeste måde at komme i gang med Atomikos.

5.1. Instantierende UserTransaction

Vi vil udnytte JTA UserTransaction for at afgrænse transaktionsgrænser. Alle andre trin relateret til transaktionstjeneste bliver automatisk taget hånd om. Dette inkluderer tilmelding og afnotering af ressourcer med transaktionstjenesten.

For det første er vi nødt til at instantiere en UserTransaction fra Atomikos:

UserTransactionImp utx = ny UserTransactionImp ();

5.2. Instantierende Datakilde

Derefter er vi nødt til at instantiere en Datakilde fra Atomikos. Der er to versioner af Datakilde som Atomikos stiller til rådighed.

Den første, AtomikosDataSourceBean, er opmærksom på en underliggende XADataSource:

AtomikosDataSourceBean dataSource = ny AtomikosDataSourceBean ();

Mens AtomikosNonXADataSourceBean bruger enhver almindelig JDBC-førerklasse:

AtomikosNonXADataSourceBean dataSource = ny AtomikosNonXADataSourceBean ();

Som navnet antyder, AtomikosNonXADataSource er ikke XA-kompatibel. Derfor kan transaktioner, der udføres med en sådan datakilde, ikke garanteres at være atomare. Så hvorfor ville vi nogensinde bruge dette? Vi har muligvis en database, der ikke understøtter XA-specifikation. Atomikos forbyder os ikke at bruge en sådan datakilde og forsøger stadig at levere atomicitet, hvis der er en enkelt sådan datakilde i transaktionen. Denne teknik svarer til Last Resource Gambit, en variation af to-faset forpligte processen.

Desuden er vi nødt til at konfigurere Datakilde afhængigt af database og driver.

5.3. Udførelse af databaseoperationer

Når det er konfigureret, er det ret nemt at bruge Datakilde inden for rammerne af en transaktion i vores ansøgning:

public void placeOrder (String productId, int amount) kaster Undtagelse {String orderId = UUID.randomUUID (). toString (); boolsk tilbageførsel = falsk; prøv {utx.begin (); ForbindelsesinventarConnection = inventarDataSource.getConnection (); ForbindelsesordreConnection = orderDataSource.getConnection (); Erklæring s1 = lagerConnection.createStatement (); Streng q1 = "opdater beholdning balance = balance -" + beløb + "hvor productId = '" + productId + "'"; s1.executeUpdate (q1); s1.close (); Erklæring s2 = orderConnection.createStatement (); String q2 = "indsæt i ordreværdier ('" + orderId + "', '" + productId + "'," + mængde + ")"; s2.executeUpdate (q2); s2.close (); lagerConnection.close (); orderConnection.close (); } fange (Undtagelse e) {rollback = sand; } endelig {if (! rollback) utx.commit (); ellers utx.rollback (); }}

Her opdaterer vi databasetabellerne for lager og ordre inden for transaktionsgrænsen. Dette giver automatisk fordelen ved, at disse operationer sker atomisk.

5.4. Test af transaktionsadfærd

Endelig skal vi være i stand til at teste vores ansøgning med enkle enhedstests for at validere, at transaktionsadfærden er som forventet:

@Test offentlig ugyldighed testPlaceOrderSuccess () kaster undtagelse {int beløb = 1; lang initialBalance = getBalance (lagerDataSource, productId); Applikationsapplikation = ny applikation (inventarDataSource, orderDataSource); application.placeOrder (productId, beløb); long finalBalance = getBalance (inventoryDataSource, productId); assertEquals (initialBalance - beløb, finalBalance); } @ Test offentlig ugyldig testPlaceOrderFailure () kaster undtagelse {int beløb = 10; lang initialBalance = getBalance (lagerDataSource, productId); Applikationsapplikation = ny applikation (inventarDataSource, orderDataSource); application.placeOrder (productId, beløb); long finalBalance = getBalance (inventoryDataSource, productId); assertEquals (initialBalance, finalBalance); }

Her, vi forventer en gyldig ordre til at formindske beholdningen, mens vi forventer, at en ugyldig ordre efterlader beholdningen uændret. Bemærk, at i henhold til vores databasebegrænsning betragtes enhver ordre med en mængde på mere end fem af et produkt som en ugyldig ordre.

5.5. Avanceret brug af Atomikos

Eksemplet ovenfor er den enkleste måde at bruge Atomikos på og måske tilstrækkelig til de fleste af kravene. Der er dog andre måder, hvorpå vi kan bruge Atomikos til at opbygge vores applikation. Mens nogle af disse muligheder gør Atomikos nemme at bruge, tilbyder andre mere fleksibilitet. Valget afhænger af vores krav.

Det er det selvfølgelig ikke nødvendigt at altid bruge Atomikos-adaptere til JDBC / JMS. Vi kan vælge at bruge Atomikos transaktionschef, mens vi arbejder direkte med XAResource. I så fald skal vi dog eksplicit sørge for at tilmelde og fjerne notering XAResource tilfælde med transaktionstjenesten.

Atomikos gør det også muligt at bruge mere avancerede funktioner gennem en proprietær grænseflade, UserTransactionService. Ved hjælp af denne grænseflade kan vi eksplicit registrere ressourcer til genopretning. Dette giver os en finkornet kontrol over, hvilke ressourcer der skal inddrives, hvordan de skal inddrives, og hvornår opsving skal ske.

6. Integrering af Atomikos

Mens Atomikos yder fremragende support til distribuerede transaktioner, er det ikke altid praktisk at arbejde med sådanne API'er på lavt niveau. For at fokusere på forretningsdomænet og undgå rod af kedelpladekode har vi ofte brug for støtte fra forskellige rammer og biblioteker. Atomikos understøtter de fleste af de populære Java-rammer relateret til back-end-integrationer. Vi udforsker et par af dem her.

6.1. Atomikos med forår og Datakilde

Spring er en af ​​de populære rammer i Java, der giver en Inversion of Control (IoC) container. Især har den også fantastisk support til transaktioner. Det tilbyder deklarativ transaktionsstyring ved hjælp af Aspect-Oriented Programming (AOP) teknikker.

Spring understøtter flere transaktions-API'er, herunder JTA til distribuerede transaktioner. Vi kan bruge Atomikos som vores JTA-transaktionschef inden for foråret uden megen anstrengelse. Vigtigst er det, at vores ansøgning forbliver temmelig agnostisk for Atomikos takket være foråret.

Lad os se, hvordan vi kan løse vores tidligere problem, denne gang ved hjælp af Spring. Vi begynder med at omskrive Ansøgning klasse:

offentlig klasse Application {private DataSource inventoryDataSource; privat DataSource orderDataSource; offentlig applikation (DataSource inventoryDataSource, DataSource orderDataSource) {this.inventoryDataSource = lagerDataSource; this.orderDataSource = orderDataSource; } @Transactional (rollbackFor = Exception.class) public void placeOrder (String productId, int amount) kaster Exception {String orderId = UUID.randomUUID (). ToString (); ForbindelsesinventarConnection = inventarDataSource.getConnection (); ForbindelsesordreConnection = orderDataSource.getConnection (); Erklæring s1 = lagerConnection.createStatement (); Streng q1 = "opdater lagersaldo = saldo -" + beløb + "hvor productId = '" + productId + "'"; s1.executeUpdate (q1); s1.close (); Erklæring s2 = orderConnection.createStatement (); Streng q2 = "indsæt i ordreværdier ('" + orderId + "', '" + productId + "'," + mængde + ")"; s2.executeUpdate (q2); s2.close (); lagerConnection.close (); orderConnection.close (); }}

Som vi kan se her, det meste af den transaktionsrelaterede kedelplatekode er blevet erstattet af en enkelt kommentar på metodeniveau. Desuden tager Spring sig af instantering og injektion Datakilde, som vores ansøgning afhænger af.

Selvfølgelig skal vi levere relevante konfigurationer til Spring. Vi kan bruge en simpel Java-klasse til at konfigurere disse elementer:

@Configuration @EnableTransactionManagement offentlig klasse Config {@Bean (initMethod = "init", destroyMethod = "close") offentlig AtomikosDataSourceBean lagerDataSource () {AtomikosDataSourceBean dataSource = ny AtomikosDataSourceBean (); // Konfigurer database indeholdende ordredata retur dataSource; } @Bean (initMethod = "init", destroyMethod = "close") offentlig AtomikosDataSourceBean orderDataSource () {AtomikosDataSourceBean dataSource = ny AtomikosDataSourceBean (); // Konfigurer database indeholdende ordredata retur dataSource; } @Bean (initMethod = "init", destroyMethod = "close") offentlig UserTransactionManager userTransactionManager () kaster SystemException {UserTransactionManager userTransactionManager = ny UserTransactionManager (); userTransactionManager.setTransactionTimeout (300); userTransactionManager.setForceShutdown (sand); returner userTransactionManager; } @Bean public JtaTransactionManager jtaTransactionManager () kaster SystemException {JtaTransactionManager jtaTransactionManager = ny JtaTransactionManager (); jtaTransactionManager.setTransactionManager (userTransactionManager ()); jtaTransactionManager.setUserTransaction (userTransactionManager ()); returnere jtaTransactionManager; } @Bean offentlig applikationsapplikation () {returner ny applikation (lagerDataSource (), orderDataSource ()); }}

Her konfigurerer vi AtomikosDataSourceBean til de to forskellige databaser, der indeholder vores lager- og ordredata. Desuden leverer vi også den nødvendige konfiguration til JTA-transaktionsadministratoren.

Nu kan vi teste vores ansøgning om transaktionsadfærd som før. Igen skal vi validere, at en gyldig ordre reducerer vores beholdningssaldo, mens en ugyldig ordre efterlader den uændret.

6.2. Atomikos med forår, JPA og dvale

Mens Spring har hjulpet os med at skære kedelpladekoden til en vis grad, er den stadig ret detaljeret. Nogle værktøjer kan gøre arbejdet med relationsdatabaser i Java endnu lettere. Java Persistence API (JPA) er en specifikation, der beskriver styringen af ​​relationsdata i Java-applikationer. Dette forenkler datatilgang og manipulationskode i vid udstrækning.

Dvaletilstand er en af ​​de mest populære implementeringer af JPA-specifikationen. Atomikos har stor støtte til flere JPA-implementeringer, inklusive dvale. Som før forbliver vores ansøgning agnostisk for Atomikos såvel som dvale takket være Spring og JPA!

Lad os se hvordan Spring, JPA og Hibernate kan gøre vores ansøgning endnu mere kortfattet og samtidig give fordelene ved distribuerede transaktioner gennem Atomikos. Som før begynder vi med at omskrive Ansøgning klasse:

public class Application {@Autowired private InventoryRepository inventoryRepository; @Autowired privat OrderRepository orderRepository; @Transactional (rollbackFor = Exception.class) public void placeOrder (String productId, int amount) kaster SQLException {String orderId = UUID.randomUUID (). ToString (); Lagerbeholdning = lagerRepository.findOne (productId); lager.setBalance (lager.getBalance () - beløb); lagerRepository.save (lager); Ordreordre = ny ordre (); order.setOrderId (orderId); order.setProductId (productId); order.setAmount (ny lang (beløb)); orderRepository.save (ordre); }}

Som vi kan se, har vi ikke at gøre med nogen database-API'er på lavt niveau nu. For at denne magi skal fungere, er vi dog nødt til at konfigurere Spring Data JPA-klasser og konfigurationer. Vi begynder med at definere vores domæneenheder:

@Entity @Table (name = "INVENTORY") offentlig klasse Inventory {@Id private String productId; privat Lang balance; // Getters og Setters}
@Entity @Table (name = "ORDERS") offentlig klasse Bestil {@Id privat String orderId; private String productId; @Max (5) privat Langt beløb; // Getters og Setters}

Dernæst er vi nødt til at give arkiverne til disse enheder:

@Repository public interface InventoryRepository udvider JpaRepository {} @Repository public interface OrderRepository udvider JpaRepository {}

Dette er ganske enkle grænseflader, og Spring Data sørger for at udarbejde disse med faktisk kode for at arbejde med databaseenheder.

Endelig er vi nødt til at levere de relevante konfigurationer til en datakilde til både lager- og ordrebaser og transaktionsadministratoren:

@Configuration @EnableJpaRepositories (basePackages = "com.baeldung.atomikos.spring.jpa.inventory", entityManagerFactoryRef = "lagerEntityManager", transactionManagerRef = "transactionManager") offentlig klasse InventoryConfig {@Bean (initMethodModeth = = init) ") offentlig AtomikosDataSourceBean lagerDataSource () {AtomikosDataSourceBean dataSource = ny AtomikosDataSourceBean (); // Konfigurer datakildens returdatakilde; } @Bean public EntityManagerFactory inventoryEntityManager () {HibernateJpaVendorAdapter vendorAdapter = new HibernateJpaVendorAdapter (); LocalContainerEntityManagerFactoryBean fabrik = ny LocalContainerEntityManagerFactoryBean (); factory.setJpaVendorAdapter (leverandøradapter); // Konfigurer enhedsadministratorens fabriksreturfabrik.getObject (); }}
@Configuration @EnableJpaRepositories (basePackages = "com.baeldung.atomikos.spring.jpa.order", entityManagerFactoryRef = "orderEntityManager", transactionManagerRef = "transactionManager") offentlig klasse OrderConfig {@Bean (initMethod = "init", destroyMethod ") offentlig AtomikosDataSourceBean ordreDataSource () {AtomikosDataSourceBean dataSource = ny AtomikosDataSourceBean (); // Konfigurer datakildens returdataSource; } @Bean public EntityManagerFactory orderEntityManager () {HibernateJpaVendorAdapter vendorAdapter = new HibernateJpaVendorAdapter (); LocalContainerEntityManagerFactoryBean fabrik = ny LocalContainerEntityManagerFactoryBean (); factory.setJpaVendorAdapter (leverandøradapter); // Konfigurer enhedsadministratorens fabriksreturfabrik.getObject (); }}
@Configuration @EnableTransactionManagement public class Config {@Bean (initMethod = "init", destroyMethod = "close") offentlig UserTransactionManager userTransactionManager () kaster SystemException {UserTransactionManager userTransactionManager = ny UserTransactionManager (); userTransactionManager.setTransactionTimeout (300); userTransactionManager.setForceShutdown (sand); returner userTransactionManager; } @Bean public JtaTransactionManager transactionManager () kaster SystemException {JtaTransactionManager jtaTransactionManager = ny JtaTransactionManager (); jtaTransactionManager.setTransactionManager (userTransactionManager ()); jtaTransactionManager.setUserTransaction (userTransactionManager ()); returnere jtaTransactionManager; } @Bean offentlig applikationsapplikation () {returner ny applikation (); }}

Dette er stadig en hel del konfiguration, som vi skal gøre. Dette skyldes dels, at vi konfigurerer Spring JPA til to separate databaser. Vi kan også reducere disse konfigurationer yderligere gennem Spring Boot, men det er uden for omfanget af denne tutorial.

Som før kan vi teste vores ansøgning om den samme transaktionsadfærd. Der er ikke noget nyt denne gang, bortset fra det faktum, at vi bruger Spring Data JPA med Hibernate nu.

7. Atomikos Beyond JTA

Mens JTA yder fremragende transaktionsunderstøttelse til distribuerede systemer, skal disse systemer være XA-klage som de fleste relationsdatabaser eller meddelelseskøer. Imidlertid, JTA er ikke nyttigt, hvis et af disse systemer ikke understøtter XA-specifikation til en to-faset forpligtelsesprotokol. Flere ressourcer falder ind under denne kategori, især inden for en mikrotjenestearkitektur.

Flere alternative protokoller understøtter distribuerede transaktioner. En af disse er en variation af tofaset forpligtelsesprotokol, der gør brug af kompensationer. Sådanne transaktioner har en afslappet isolationsgaranti og er kendt som kompensationsbaserede transaktioner. Deltagerne forpligter de enkelte dele af transaktionen i selve første fase og tilbyder en kompensationshåndterer for en mulig tilbageførsel i anden fase.

Der er flere designmønstre og algoritmer til implementering af en kompensationsbaseret transaktion. For eksempel er Sagas et sådant populært designmønster. De er dog normalt komplekse at implementere og være udsatte for fejl.

Atomikos tilbyder en variation af kompensationsbaseret transaktion kaldet Try-Confirm / Cancel (TCC). TCC tilbyder bedre forretningssemantik til enhederne under en transaktion. Dette er dog kun muligt med avanceret arkitektursupport fra deltagerne, og TCC er kun tilgængelig under Atomikos kommercielle tilbud, ExtremeTransactions.

8. Alternativer til Atomikos

Vi har gennemgået nok af Atomikos til at værdsætte, hvad det har at tilbyde. Desuden er der et kommercielt tilbud fra Atomikos med endnu mere kraftfulde funktioner. Atomikos er dog ikke den eneste mulighed, når det kommer til at vælge en JTA-transaktionschef. Der er et par andre pålidelige muligheder at vælge imellem. Lad os se, hvordan de klarer sig mod Atomikos.

8.1. Narayana

Narayana er måske en af ​​de ældste distribuerede transaktionsledere med open source og administreres i øjeblikket af Red Hat. Det er blevet udbredt i hele branchen, og det har udviklet sig gennem samfundsstøtte og påvirket adskillige specifikationer og standarder.

Narayana yder support til en lang række transaktionsprotokoller som JTA, JTS, Web-Services og REST, for at nævne nogle få. Yderligere kan Narayana indlejres i en lang række containere.

Sammenlignet med Atomikos giver Narayana stort set alle funktionerne i en distribueret transaktionsmanager. I mange tilfælde er Narayana mere fleksibel til at integrere og bruge i applikationer. For eksempel har Narayana sprogbindinger til både C / C ++ og Java. Dette kommer dog på bekostning af ekstra kompleksitet, og Atomikos er relativt lettere at konfigurere og bruge.

8.2. Bitronix

Bitronix er en fuldt fungerende XA-transaktionsmanager, der leverer alle de tjenester, der kræves af JTA API. Det er vigtigt, at Bitronix er et integreret transaktionsbibliotek, der giver omfattende og nyttig fejlrapportering og logføring. For en distribueret transaktion gør det det lettere at undersøge fejl. Desuden har den fremragende support til Spring's transaktionsfunktioner og fungerer med minimale konfigurationer.

Sammenlignet med Atomikos er Bitronix et open source-projekt og har ikke et kommercielt tilbud med produktsupport. De vigtigste funktioner, der er en del af Atomikos 'kommercielle tilbud, men som mangler i Bitronix, inkluderer understøttelse af mikrotjenester og deklarativ elastisk skaleringsfunktion.

9. Konklusion

For at opsummere gik vi i denne vejledning gennem de grundlæggende detaljer i transaktioner. Vi forstod, hvad distribuerede transaktioner er, og hvordan et bibliotek som Atomikos kan gøre det lettere at udføre dem. I processen udnyttede vi Atomikos API'er til at skabe en simpel applikation med distribuerede transaktioner.

Vi forstod også, hvordan Atomikos fungerer med andre populære Java-rammer og biblioteker. Endelig gennemgik vi nogle af de alternativer til Atomikos, der er tilgængelige for os.

Som normalt kan kildekoden til denne artikel findes på GitHub.


$config[zx-auto] not found$config[zx-overlay] not found