streamalism.org

1. Bemutatkozás

Ebben az oktatóanyagban megértjük, mit jelentenek a Java-ban végzett tranzakciók. Ezáltal megértjük az erőforrás helyi és globális tranzakcióinak végrehajtását. Ez lehetővé teszi számunkra a Java és a Spring tranzakcióinak kezelésének különböző módjainak feltárását is.

2. Mi az a tranzakció?

A Java-ban végrehajtott tranzakciók általában olyan műveletek sorozatára utalnak, amelyeket mind sikeresen be kell fejezni. Ennélfogva, ha egy vagy több művelet sikertelen, akkor az összes többi műveletnek ki kell lépnie, és az alkalmazás állapota változatlan marad. Erre azért van szükség, hogy soha ne sérüljön az alkalmazás állapotának integritása.

Ezenkívül ezek a tranzakciók egy vagy több erőforrást is magukban foglalhatnak, például adatbázist, üzenetsort, ami különböző módokat eredményezhet egy tranzakció alatti műveletek végrehajtására. Ide tartozik az erőforrás helyi tranzakcióinak végrehajtása az egyes erőforrásokkal. Alternatív megoldásként több erőforrás is részt vehet egy globális tranzakcióban.

3. Forrás helyi tranzakciók

Először feltárjuk, hogyan használhatjuk a Java-ban végzett tranzakciókat, miközben egyéni erőforrásokkal dolgozunk. Itt lehet több egyedi művelet, amelyet olyan erőforrással hajtunk végre, mint egy adatbázis. De azt szeretnénk, ha egységes egészként történnének meg, mint egy oszthatatlan munkaegységben. Más szóval azt akarjuk, hogy ezek a műveletek egyetlen tranzakció alatt történjenek.

A Java-ban többféle módon érhetjük el és kezelhetjük az erőforrásokat, például egy adatbázist. Ezért a tranzakciók kezelése sem ugyanaz. Ebben a szakaszban megtudhatjuk, hogyan használhatjuk a tranzakciókat ezeknek a Java könyvtáraknak néhányával, amelyeket gyakran használnak.

3.1. JDBC

A Java Database Connectivity (JDBC) az a Java-ban lévő API, amely meghatározza a Java-adatbázisok elérésének módját. Különböző adatbázis-gyártók biztosítják a JDBC illesztőprogramokat, hogy szállítói-agnosztikus módon csatlakozzanak az adatbázishoz. Tehát lekérjük a Kapcsolat illesztőprogramtól különböző műveletek végrehajtásához az adatbázisban:

A JDBC lehetőséget nyújt számunkra, hogy tranzakción belül utasításokat hajtsunk végre. A alapértelmezett viselkedése a Kapcsolat az automatikus elkötelezettség. Hogy tisztázzuk, ez azt jelenti, hogy minden egyes kimutatást tranzakcióként kezelnek, és a végrehajtás után automatikusan végrehajtják.

Ha azonban több tranzakciót akarunk egy tranzakcióba csomagolni, akkor ezt is meg lehet valósítani:

Csatlakozási kapcsolat = DriverManager.getConnection (CONNECTION_URL, USER, PASSWORD); próbáld ki a {connection.setAutoCommit (hamis); PreparedStatement firstStatement = kapcsolat .prepareStatement ("firstQuery"); firstStatement.executeUpdate (); PreparedStatement secondStatement = kapcsolat .prepareStatement ("secondQuery"); secondStatement.executeUpdate (); connection.commit (); } catch (e kivétel) {connection.rollback (); }

Itt letiltottuk az automatikus véglegesítési módot Kapcsolat. Ezért megtehetjük kézzel határozza meg a tranzakció határát, és hajtsa végre a elkövetni vagy visszagörgetés. A JDBC lehetővé teszi számunkra a Savepoint így jobban ellenőrizhetjük, mennyit kell visszagörgetni.

3.2. JPA

A Java Persistence API (JPA) a Java specifikációja, amelyhez használható áthidalja a szakadékot az objektum-orientált tartománymodellek és a relációs adatbázis-rendszerek között. Tehát a JPA számos megvalósítását elérhetővé teszik harmadik felek, például a Hibernate, az EclipseLink és az iBatis.

A JPA-ban a reguláris osztályokat definiálhatjuk Entitás amely állandó identitást biztosít számukra. A EntityManager osztály biztosítja a szükséges felületet ahhoz, hogy egy perzisztencia-kontextusban több entitással dolgozzon. A perzisztencia-kontextus első szintű gyorsítótárnak tekinthető, ahol az entitásokat kezelik:

A perzisztencia-kontextus itt kétféle lehet, tranzakciós vagy kiterjesztett körű. A tranzakció hatókörű perzisztencia-kontextus egyetlen tranzakcióhoz van kötve. Míg a kibővített hatókörű perzisztencia-kontextus több tranzakcióra is kiterjedhet. A a perzisztencia-kontextus alapértelmezett hatóköre tranzakciós hatókör.

Lássuk, hogyan hozhatunk létre egy EntityManager és kézzel határozza meg a tranzakció határát:

EntityManagerFactory entitásManagerFactory = Persistence.createEntityManagerFactory ("jpa-example"); EntityManager entitásManager = entitásManagerFactory.createEntityManager (); próbáld ki az {entitásManager.getTransaction (). start (); entitásManager.persist (firstEntity); entitásManager.persist (secondEntity); entitásManager.getTransaction (). kötelezettség (); } catch (Exceotion e) {entityManager.getTransaction (). rollback (); }

Itt létrehozunk egy EntityManager tól től EntityManagerFactory tranzakciókörű perzisztencia-kontextusban. Ezután meghatározzuk a tranzakció határát kezdődik, elkövetni, és visszagörgetés mód.

3.3. JMS

A Java Messaging Service (JMS) a Java specifikációja, amely lehetővé teszi az alkalmazások számára az aszinkron kommunikációt üzenetek segítségével. Az API lehetővé teszi számunkra, hogy üzeneteket hozzunk létre, küldjünk, fogadjunk és olvassunk egy várólistáról vagy témáról. Számos olyan üzenetküldő szolgáltatás létezik, amelyek megfelelnek a JMS specifikációinak, beleértve az OpenMQ és az ActiveMQ szolgáltatásokat.

A JMS API támogatja a több küldés vagy fogadás műveletek kötegelését egyetlen tranzakcióban. Az üzenetalapú integrációs architektúra jellege miatt azonban az üzenet előállítása és fogyasztása nem lehet ugyanazon tranzakció része. A tranzakció hatóköre az ügyfél és a JMS szolgáltató között marad:

A JMS lehetővé teszi számunkra a Ülés a-tól Kapcsolat amelyet egy szállító-specifikustól kapunk ConnectionFactory. Van egy opció a Ülés hogy megtörténik vagy sem. Nem tranzakcióhoz Üléss, tovább meghatározhatunk egy megfelelő nyugtázási módot is.

Lássuk, hogyan hozhatunk létre tranzakciót Ülés több üzenet küldése tranzakció alatt:

ActiveMQConnectionFactory connectionFactory = új ActiveMQConnectionFactory (CONNECTION_URL); Csatlakozási kapcsolat = = connectionFactory.createConnection (); kapcsolat.indítás (); próbáld ki a {Session session = connection.createSession (true, 0); Cél = cél = munkamenet.createTopic ("TEST.FOO"); MessageProducer producer = session.createProducer (cél); producer.send (firstMessage); producer.send (secondMessage); session.commit (); } catch (e kivétel) {session.rollback (); }

Itt készítünk egy MessageProducer a Rendeltetési hely a téma típusának. Megkapjuk a Rendeltetési hely tól Ülés korábban hoztunk létre. Tovább használjuk Ülés hogy meghatározza a tranzakciós határokat a módszerek segítségével elkövetni és visszagörgetés.

4. Globális tranzakciók

Mint láttuk az erőforrás helyi tranzakciói lehetővé teszik számunkra, hogy egyetlen erőforráson belül több műveletet hajtsunk végre, egységes egységként. De elég gyakran foglalkozunk velük több erőforráson átívelő műveletek. Például két különböző adatbázisban, vagy adatbázisban és üzenetsorban történő működés. Itt az erőforrásokon belüli helyi tranzakciós támogatás nem lesz elegendő számunkra.

Amire szükségünk van ezekben a forgatókönyvekben: globális mechanizmus a több résztvevő erőforrást felölelő tranzakciók elhatárolására. Ezt gyakran elosztott tranzakcióknak nevezik, és vannak specifikációk, amelyeket a hatékony kezelésükre javasoltak.

A Az XA Specifikáció egy olyan specifikáció, amely meghatározza a tranzakciókezelőt, hogy több erőforráson keresztül ellenőrizze a tranzakciókat. A Java elég kiforrott támogatást nyújt az XA specifikációnak megfelelő elosztott tranzakciókhoz a JTA és JTS komponenseken keresztül.

4.1. JTA

A Java Transaction API (JTA) egy Java Enterprise Edition API, amelyet a Java Community Process keretében fejlesztettek ki. Azt lehetővé teszi a Java alkalmazások és alkalmazásszerverek számára, hogy elosztott tranzakciókat hajtsanak végre az XA erőforrások között. A JTA az XA architektúra köré épül, kétfázisú elkötelezettséget kihasználva.

A JTA szabványos Java interfészeket határoz meg egy tranzakciókezelő és egy elosztott tranzakció többi résztvevője között:

Értsük meg a fent kiemelt néhány legfontosabb interfészt:

• TransactionManager: Olyan felület, amely lehetővé teszi az alkalmazásszerver számára a tranzakciók elhatárolását és ellenőrzését
• UserTransaction: Ez a felület lehetővé teszi egy alkalmazás számára a tranzakciók egyértelmű elhatárolását és ellenőrzését
• XAResource: Ennek a felületnek az a célja, hogy egy tranzakciókezelő együttműködhessen az XA-kompatibilis erőforrások erőforrás-kezelőivel

4.2. JTS

A Java Transaction Service (JTS) az a tranzakciókezelő felépítésének specifikációja, amely megfelel az OMG OTS specifikációnak. A JTS a standard CORBA ORB / TS interfészeket és az Internet Inter-ORB Protocol (IIOP) protokollt használja a JTS tranzakciókezelők közötti tranzakciós kontextus terjesztésére.

Magas szinten támogatja a Java Transaction API-t (JTA). A JTS tranzakciókezelő tranzakciós szolgáltatásokat nyújt az elosztott tranzakcióban részt vevő feleknek:

A JTS által az alkalmazás számára nyújtott szolgáltatások nagyrészt átláthatók, ezért előfordulhat, hogy észre sem vesszük őket az alkalmazás architektúrájában. A JTS egy alkalmazásszerver köré épül, amely az összes tranzakciós szemantikát kivonja az alkalmazás programjaiból.

5. JTA tranzakciókezelés

Itt az ideje, hogy megértsük, hogyan kezelhetjük az elosztott tranzakciókat a JTA segítségével. Az elosztott tranzakciók nem jelentéktelen megoldások, és ezért költségvonzataik is vannak. Ráadásul, többféle lehetőség közül választhatunk a JTA felvételére az alkalmazásunkba. Ezért választásunknak a teljes alkalmazás architektúrájának és törekvéseinek szem előtt kell tartania.

5.1. JTA az alkalmazáskiszolgálón

Mint korábban láthattuk, a JTA architektúra támaszkodik az alkalmazásszerver számos tranzakcióval kapcsolatos művelet megkönnyítésére. Az egyik legfontosabb szolgáltatás, amelyet a kiszolgáló nyújt, a JNDI-n keresztüli névadási szolgáltatás. Ide kötik és lekérik az XA erőforrásokat, például az adatforrásokat.

Ettől eltekintve választhatunk arról, hogy miként akarjuk kezelni a tranzakciós határt az alkalmazásunkban. Ez kétféle tranzakciót eredményez a Java alkalmazáskiszolgálón belül:

• Konténer által kezelt tranzakció: Ahogy a neve is sugallja, itt a tranzakció határát az alkalmazáskiszolgáló határozza meg. Ez leegyszerűsíti az Enterprise Java Beans (EJB) fejlesztését, mivel nem tartalmazza a tranzakciók elhatárolásával kapcsolatos utasításokat, és kizárólag a tárolóra támaszkodik. Ez azonban nem nyújt elegendő rugalmasságot az alkalmazás számára.
• Bean által kezelt tranzakció: A konténer által kezelt tranzakcióval ellentétben babkezelt tranzakcióban Az EJB-k kifejezett utasításokat tartalmaznak a tranzakciók elhatárolásának meghatározásához. Ez pontos irányítást biztosít az alkalmazás számára a tranzakció határainak kijelölésében, bár bonyolultabb áron.

Az alkalmazáskiszolgálóval kapcsolatos tranzakciók végrehajtásának egyik fő hátránya, hogy a alkalmazás szorosan összekapcsolódik a szerverrel. Ennek következményei vannak az alkalmazás tesztelhetőségével, kezelhetőségével és hordozhatóságával kapcsolatban. Ez sokkal mélyebb a mikroszolgáltatási architektúrában, ahol a hangsúly inkább a szerversemleges alkalmazások fejlesztésén van.

5.2. JTA önálló

Az utolsó szakaszban tárgyalt problémák hatalmas lendületet adtak az alkotás felé olyan megoldások elosztott tranzakciókhoz, amelyek nem támaszkodnak alkalmazáskiszolgálóra. Számos lehetőség áll rendelkezésünkre e tekintetben, például tranzakciós támogatás használata a Spring-szel vagy egy tranzakciókezelő használata, mint az Atomikos.

Nézzük meg, hogyan használhatjuk az Atomikoshoz hasonló tranzakciókezelőt az elosztott tranzakció megkönnyítésére egy adatbázissal és egy üzenetsorral. Az elosztott tranzakció egyik legfontosabb szempontja az a résztvevő erőforrások felvétele és törlése a tranzakciómonitor segítségével. Az Atomikos gondoskodik erről helyettünk. Csak annyit kell tennünk, hogy használjuk az Atomikos által biztosított absztrakciókat:

AtomikosDataSourceBean atomikosDataSourceBean = új AtomikosDataSourceBean (); atomikosDataSourceBean.setXaDataSourceClassName ("com.mysql.cj.jdbc.MysqlXADataSource"); DataSource dataSource = atomikosDataSourceBean;

Itt létrehozunk egy példányt AtomikosDataSourceBean és az eladóspecifikus regisztrálása XADataSource. Innentől kezdve továbbra is használhatjuk ezt, mint bármely más Adatforrás és élvezze az elosztott tranzakciók előnyeit.

Hasonlóképpen mi is van egy absztrakció az üzenetsorhoz amely gondoskodik az eladó-specifikus XA erőforrás automatikus regisztrálásáról a tranzakciómonitoron:

AtomikosConnectionFactoryBean atomikosConnectionFactoryBean = new AtomikosConnectionFactoryBean (); atomikosConnectionFactoryBean.setXaConnectionFactory (új ActiveMQXAConnectionFactory ()); ConnectionFactory connectionFactory = atomikosConnectionFactoryBean;

Itt létrehozunk egy példányt AtomikosConnectionFactoryBean és a XAConnectionFactory egy XA-kompatibilis JMS-gyártótól. Ezek után ezt továbbra is használhatjuk törzsvendégként ConnectionFactory.

Most az Atomikos nyújtja nekünk a puzzle utolsó darabját, amely mindent összehoz, egy példányt UserTransaction:

UserTransaction userTransaction = new UserTransactionImp ();

Most készen állunk egy alkalmazás létrehozására, amely elosztott tranzakcióval rendelkezik az adatbázisunkban és az üzenetsorban:

próbáld ki a {userTransaction.begin (); java.sql.Connection dbConnection = dataSource.getConnection (); PreparedStatement parengtaStatement = dbConnection.prepareStatement (SQL_INSERT); PreparStatement.executeUpdate (); javax.jms.Connection mbConnection = connectionFactory.createConnection (); Munkamenet = mbConnection.createSession (true, 0); Úti cél = session.createTopic ("TEST.FOO"); MessageProducer producer = session.createProducer (cél); producer.send (ÜZENET); userTransaction.commit (); } catch (e kivétel) {userTransaction.rollback (); }

Itt használjuk a mód kezdődik és elkövetni az osztályban UserTransaction hogy kijelölje a tranzakció határát. Ez magában foglalja a rekord mentését az adatbázisban, valamint egy üzenet közzétételét az üzenetsorban.

6. Tranzakciók támogatása tavasszal

Ezt láttuk a tranzakciók kezelése meglehetősen érintett feladat, amely sok kazánlap kódolást tartalmaz és konfigurációk. Ezenkívül minden erőforrásnak megvan a maga módja a helyi tranzakciók kezelésére. A Java-ban a JTA elvonatkoztat ezekből a variációkból, de tovább hozza a szolgáltató-specifikus részleteket és az alkalmazáskiszolgáló összetettségét.

Tavaszi emelvény sokkal tisztább módot kínál a tranzakciók kezelésére, mind a helyi, mind a globális tranzakciókkal Java-ban. Ez a Spring egyéb előnyeivel együtt meggyőző esetet teremt a Spring tranzakciók kezelésére történő felhasználására. Ezenkívül nagyon könnyű konfigurálni és váltani a tranzakciókezelőt a Spring segítségével, amely lehet szerver vagy önálló.

A tavasz biztosítja ezt nekünk zökkenőmentes absztrakció a módszerek proxyjának létrehozásával tranzakciós kóddal. A proxy a kód segítségével kezeli a tranzakció állapotát a segítségével TransactionManager:

A központi interfész itt van PlatformTransactionManager amely számos különböző megvalósítással rendelkezik. Absztrakciókat biztosít a JDBC (DataSource), a JMS, a JPA, a JTA és sok más erőforrás felett.

6.1. Konfigurációk

Lássuk, hogyan tudunk konfigurálni Tavasz, hogy az Atomikoszot tranzakciókezelőként használja, és tranzakciós támogatást nyújtson a JPA és a JMS számára. Kezdjük azzal, hogy meghatározzuk a PlatformTransactionManager JTA típusú:

@Bean public PlatformTransactionManager platformTransactionManager () dobja Throwable {return new JtaTransactionManager (userTransaction () ,actionManager ()); }

Itt a UserTransaction és TransactionManager nak nek JTATransactionManager. Ezeket a példányokat egy olyan tranzakciókezelő könyvtár biztosítja, mint az Atomikos:

@Bean public UserTransaction userTransaction () {return new UserTransactionImp (); } @Bean (initMethod = "init", destrMethod = "bezárás") public TransactionManageractionManager () {return new UserTransactionManager (); }

Az osztályok UserTransactionImp és UserTransactionManager itt az Atomikos nyújtja.

Továbbá meg kell határoznunk a JmsTemplete amely szinkron JMS hozzáférést lehetővé tevő alaposztály tavasszal:

@Bean public JmsTemplate jmsTemplate () dobja Throwable {return new JmsTemplate (connectionFactory ()); }

Itt, ConnectionFactory az Atomikos nyújtja, ahol lehetővé teszi az elosztott tranzakciót Kapcsolat általa biztosított:

@Bean (initMethod = "init", destrMethod = "bezárás") public ConnectionFactory connectionFactory () {ActiveMQXAConnectionFactory activeMQXAConnectionFactory = new ActiveMQXAConnectionFactory (); activeMQXAConnectionFactory.setBrokerURL ("tcp: // localhost: 61616"); AtomikosConnectionFactoryBean atomikosConnectionFactoryBean = új AtomikosConnectionFactoryBean (); atomikosConnectionFactoryBean.setUniqueResourceName ("xamq"); atomikosConnectionFactoryBean.setLocalTransactionMode (hamis); atomikosConnectionFactoryBean.setXaConnectionFactory (aktívMQXAConnectionFactory); return atomikosConnectionFactoryBean; }

Tehát, mint láthatjuk, itt egy JMS szolgáltatóspecifikusat csomagolunk XAConnectionFactory val vel AtomikosConnectionFactoryBean.

Ezután meg kell határoznunk egy AbstractEntityManagerFactoryBean amely felelős a JPA létrehozásáért EntityManagerFactory bab tavasszal:

@Bean public LocalContainerEntityManagerFactoryBean entitásManager () dobja az SQLException {LocalContainerEntityManagerFactoryBean entitásManager = új LocalContainerEntityManagerFactoryBean (); entitásManager.setDataSource (dataSource ()); Tulajdonságok tulajdonságai = új Tulajdonságok (); properties.setProperty ("javax.persistence.transactionType", "jta"); entitásManager.setJpaProperties (tulajdonságok); return entitásManager; }

Mint korábban, a Adatforrás hogy beállítottuk a LocalContainerEntityManagerFactoryBean itt az Atomikos biztosítja az engedélyezett elosztott tranzakciókat:

@Bean (initMethod = "init", destrMethod = "bezár") public DataSource dataSource () dobja az SQLException {MysqlXADataSource mysqlXaDataSource = új MysqlXADataSource (); mysqlXaDataSource.setUrl ("jdbc: mysql: //127.0.0.1: 3306 / teszt"); AtomikosDataSourceBean xaDataSource = új AtomikosDataSourceBean (); xaDataSource.setXaDataSource (mysqlXaDataSource); xaDataSource.setUniqueResourceName ("xads"); return xaDataSource; }

Ismét itt csomagoljuk a szolgáltatóspecifikusat XADataSource ban ben AtomikosDataSourceBean.

6.2. Tranzakciók kezelése

Miután végigvittük az utolsó szakasz összes konfigurációját, eléggé le kell borulnunk! Mégis megkérdőjelezhetjük a Spring használatának előnyeit. De ne feledje, hogy ennek a konfigurációnak megvan lehetővé tette számunkra az absztrakciót a szolgáltató-specifikus kazánból és a tényleges alkalmazási kódunknak egyáltalán nem kell tudatában lennie.

Tehát most készen állunk arra, hogy megvizsgáljuk, hogyan lehet tavasszal használni a tranzakciókat, ahol az adatbázis frissítését és az üzenetek közzétételét tervezzük. A tavasz két módot kínál számunkra, hogy ezt elérjük a saját előnyeikkel, amelyek közül választhatunk. Értsük meg, hogyan használhatjuk fel őket:

• Nyilatkozati támogatás

A tranzakciók tavasszal a legegyszerűbb módja a deklaratív támogatás. Itt van a módszerhez vagy akár az osztályhoz alkalmazható kényelmi jegyzet. Ez egyszerűen lehetővé teszi a kódunk globális tranzakcióját:

@PersistenceContext EntityManager entitásManager; @Autowired JmsTemplate jmsTemplate; @Transactionional (propagation = Propagation.REQUIRED) public void process (ENTITY, MESSAGE) {entitásManager.persist (ENTITY); jmsTemplate.convertAndSend (CÉL, ÜZENET); }

A fenti egyszerű kód elegendő az adatbázis-mentési művelet és a JTA-tranzakción belüli üzenetsorban történő közzétételi művelet engedélyezéséhez.

• Programozási támogatás

Bár a deklaratív támogatás meglehetősen elegáns és egyszerű, nem kínálja fel nekünk a előnye a tranzakció határának pontosabb ellenőrzésének. Ennélfogva, ha bizonyos igényünk van ennek elérésére, Spring programozási támogatást kínál a tranzakciós határok lehatárolásához:

@Autowired private PlatformTransactionManageractionManager; public void folyamat (ENTITY, MESSAGE) {TransactionTemplateactionTemplate = new TransactionTemplate (tranzakciókezelő); ügyletTemplate.executeWithoutResult (állapot -> {entitásManager.persist (ENTITY); jmsTemplate.convertAndSend (CÉL, ÜZENET;}); }

Tehát, amint láthatjuk, létre kell hoznunk a TransactionTemplate a rendelkezésre állóval PlatformTransactionManager. Akkor használhatjuk a TransactionTemplete egy csomó kimutatás feldolgozásához egy globális tranzakción belül.

7. Utángondolások

Amint láttuk, a tranzakciók kezelése, különösen azok, amelyek több erőforráson átívelnek, összetett. Ráadásul, a tranzakciók eleve blokkolják, ami káros a késleltetés és az áteresztőképesség szempontjából egy alkalmazás. Továbbá a kód tesztelése és karbantartása elosztott tranzakciókkal nem könnyű, különösen, ha a tranzakció az alapul szolgáló alkalmazáskiszolgálótól függ. Összességében tehát a legjobb, ha egyáltalán elkerüljük a tranzakciókat!

De ez messze van a valóságtól. Röviden, a valós alkalmazásokban gyakran jogos igényünk van a tranzakciókra. Bár az tranzakciók nélkül át lehet gondolni az alkalmazás architektúráját, nem mindig lehetséges. Ezért el kell fogadnunk bizonyos bevált gyakorlatokat a Java-ban végzett tranzakciók során, hogy jobbá tegyük alkalmazásainkat:

• Az egyik alapvető váltás, amelyet el kell fogadnunk, az használjon önálló tranzakciókezelőket az alkalmazáskiszolgáló által biztosítottak helyett. Ez önmagában jelentősen leegyszerűsítheti alkalmazásunkat. Ráadásul kiválóan alkalmas felhőalapú mikroszolgáltatás-architektúrára.
• További, egy olyan absztrakciós réteg, mint a Spring, segíthet a szolgáltatók közvetlen hatásainak megfékezésében mint a JPA vagy a JTA szolgáltatók. Tehát ez lehetővé teheti a szolgáltatók közötti váltást anélkül, hogy az üzleti logikánkra nagy hatást gyakorolna. Sőt, elveszi tőlünk a tranzakciós állapot kezelésének alacsony szintű felelősségét.
• Végül pedig nekünk kellene körültekintően válassza ki a tranzakció határát a kódunkban. Mivel a tranzakciók blokkolva vannak, mindig jobb, ha a tranzakció határát a lehető legszűkebben tartják. Szükség esetén előnyben kell részesítenünk a tranzakcióknál az automatizálást, a deklaratív ellenőrzés helyett.

8. Következtetés

Összegezve: ebben az oktatóanyagban a Java kontextusában tárgyaltuk a tranzakciókat. Támogattuk az egyes erőforrások helyi Java-tranzakcióit különböző erőforrásokhoz. Végigjártuk a globális tranzakciók megvalósítását a Java-ban is.

Ezenkívül a Java-ban végzett globális tranzakciók kezelésének különböző módjain mentünk keresztül. Megértettük azt is, hogy a Spring hogyan könnyíti meg számunkra a Java-ban végzett tranzakciókat.

Végül áttekintettük a legjobb gyakorlatokat, amikor a Java-ban végzett tranzakciókkal dolgoztunk.