Ex­tremeTrans­ac­tions 5.0

XA trans­ac­tions for mi­croser­vices and the cloud

XA trans­ac­tions for mi­croser­vices and the cloud

Up­grad­ing from 4.0

Up­grad­ing should be easy, and in case you have is­sues then do the fol­low­ing to get back­ward com­pat­i­bil­i­ty:

• Set lo­calTrans­ac­tionMode=true on your JDBC data­source(s)
• In jta.prop­er­ties, set com.atom­ikos.icatch.throw_on_heuris­tic=true

IMPORTANT: since the log file for­mat has changed, make sure to do a clean shut­down first so you can safe­ly re­move the ex­ist­ing trans­ac­tion logs.

Re­mot­ing sup­port for mi­croser­vices

Ever heard of ACID trans­ac­tions be­ing an anti-pat­tern? Most­ly this is be­cause peo­ple don't know how to do it. This has now changed!

Check out ex­am­ples-jta-rest-jaxrs to see how easy it is to com­mit or roll­back across mul­ti­ple ser­vices.

Sim­ple Trans­ac­tionTem­plate

Maybe you use Spring, maybe you don't. Either way, you can now use our new com.atom­ikos.icatch.jta.tem­plate.Trans­ac­tionTem­plate to de­mar­cate trans­ac­tions with the known se­man­tics (REQUIRED, REQUIRES_NEW, MANDATORY, NEVER, SUPPORTS, NOT_SUPPORTED and NESTED). Lamb­da's are sup­port­ed, too.

No throw­ing of heuris­tic ex­cep­tions

We no longer throw on heuris­tic ex­cep­tions - be­cause heuris­tics are an op­er­a­tions is­sue, not a de­vel­op­er is­sue. How­ev­er, if your code de­pends on heuris­tics then you can switch on the old be­hav­iour in jta.prop­er­ties like this:

com.atomikos.icatch.throw_on_heuristic=true

New and sim­pli­fied re­cov­ery

We've made re­cov­ery even sim­pler, so it works bet­ter and faster - even in the cloud: your ap­pli­ca­tion's trans­ac­tion pro­cess­ing now mere­ly in­serts log records, and all oth­er pro­cess­ing and cleanup is done in the back­ground (by the re­cov­ery sub­sys­tem). This achieves the ul­ti­mate and com­plete sep­a­ra­tion of con­cerns be­tween OLTP log­ic and re­cov­ery log­ic. The logs are also more com­pact be­cause we no longer store in­di­vid­ual XIDs.

Au­to­mat­ic archiv­ing of heuris­tic prob­lems

Heuris­tic prob­lem cas­es are now most­ly archived au­to­mat­i­cal­ly so they will no longer "pol­lute" the log files. Your ap­pli­ca­tion can cap­ture de­tails with our event API - so you can log what­ev­er you need to deal with such prob­lems.

The LogAd­min­is­tra­tor in­ter­face had been re­moved from our API be­cause it be­came ob­so­lete now that we deal with heuris­tics au­to­mat­i­cal­ly.

Fil­ter out "du­pli­cate" re­sources for re­cov­ery

With the 4.0 re­cov­ery, mul­ti­ple con­nec­tion fac­to­ries or data­source to the same back­end would lead to many re­cov­ery calls. Now we fil­ter out du­pli­cates - so each backed is only re­cov­ered once dur­ing each re­cov­ery scan.

Easy proxy cre­ation

We've added sup­port for easy and el­e­gant dy­nam­ic proxy cre­ation. This means that we can have bet­ter prox­ies (typ­i­cal­ly need­ed for JTA en­list/delist). Our JDBC and JMS mod­ules have been refac­tored to lever­age this new de­sign.

API sim­pli­fi­ca­tion

We've sim­pli­fied our (in­ter­nal) API based on in­sights we've col­lect­ed over the years. Most no­tably, our API no longer re­quires Se­ri­al­iz­able sup­port and the trans­ac­tion im­port/ex­port mech­a­nism has also been cleaned up to al­low for el­e­gant HTTP / mi­croser­vice trans­ac­tions.

Im­proved JDBC Non-XA sup­port

The class­es for the non-XA data­source have been im­proved for more safe­ty and flex­i­bil­i­ty:

• Sub­trans­ac­tions are now sup­port­ed
• Mul­ti­ple read-only in­stances can be used in the same trans­ac­tion
• Non-read-only in­stances will fail if used in two-phase com­mit

Here are some rel­e­vant GitHub is­sues:

• https://github.com/atom­ikos/trans­ac­tions-es­sen­tials/is­sues/83
• https://github.com/atom­ikos/trans­ac­tions-es­sen­tials/is­sues/85

Also, the class AtomikosNonXADataSourceBean has now been moved into pack­age com.atom­ikos.jdbc (along­side our AtomikosDataSourceBean).

Safer JDBC de­sign

We used to al­low a mix of lo­cal trans­ac­tions and JTA trans­ac­tions (de­pend­ing on whether a JTA trans­ac­tion ex­ist­ed or not). As of this re­lease, only JTA trans­ac­tions are al­lowed for JDBC - un­less ex­plic­it­ly over­rid­den by set­ting "lo­calTrans­ac­tionMode=true" on any of our data­sources.

JDBC state­ment house­keep­ing

We no longer keep JDBC state­ments af­ter they are closed, which means less mem­o­ry con­sump­tion.

Jm­sSen­derTem­plateCall­back is a func­tion­al in­ter­face

For the lamb­da lovers: you can now do these with the Jm­sSen­derTem­plateCall­back.

Ex­am­ple with Hiber­nate 5

We've in­clud­ed a work­ing sam­ple with hi­ber­nate 5

Ex­am­ple with Spring 5.1

We've up­grad­ed the Spring ex­am­ple to use a re­cent ver­sion of Spring.

Re­moved JUL log­ger from ex­am­ples

Some peo­ple thought we had a JUL log­ger de­pen­den­cy in the ex­am­ples. This has now been re­moved.

High-per­for­mance JMS batch pro­cess­ing

In mod­ule trans­ac­tions-spring we have added com.atom­ikos.spring.Batch­ingMes­sageLis­ten­erCon­tain­er. This is an ex­ten­sion of Spring's De­fault­Mes­sageLis­ten­erCon­tain­er that adds batched pro­cess­ing of mul­ti­ple JMS mes­sages. In all our tests this has sig­nif­i­cant­ly im­proved per­for­mance. This is a nice ex­am­ple where XA can ac­tu­al­ly make things faster in­stead of slow­er...

Spring Boot 2

Us­ing Spring Boot (2)? No prob­lem, we sup­port that!

Mon­i­tor­ing (op­er­a­tions) por­tal

We've added lots of in­ter­est­ing core events to be mon­i­tored, and a mon­i­tor­ing mod­ule to log these events - so you can use your favourite log analy­sis tools to mon­i­tor your dis­trib­uted trans­ac­tions. The trans­ac­tion ID serves as the cor­re­la­tion ID.

En­hanced sup­port for Al­le­groGraph with JTA

The Al­le­groGraph graph/NoSQL data­base sys­tem sup­ports XA but not easy JTA en­list­ment - leav­ing it to your ap­pli­ca­tion to en­list low-lev­el XARe­source in­stances with the JTA trans­ac­tion. We've added sup­port for this, so you don't have to both­er any more: you can now use Al­le­groGraph with the same lev­el of com­fort and ease as you can do reg­u­lar JDBC or JMS with trans­ac­tions.

See Con­fig­ur­ing Al­le­groGraph for JTA/XA with Atomikos for de­tails.

En­hanced sup­port for Hazel­cast with JTA

Like Al­le­groGraph, Hazel­cast does not sup­port JTA/XA at a high lev­el (so you end up do­ing XA op­er­a­tions your­self). This has been im­proved: we now do this for you, be­hind the scenes.

See Con­fig­ur­ing Hazel­cast for JTA/XA with Atomikos for de­tails.

LogCloud with DBMS stor­age

We've made the LogCloud bet­ter, based on feed­back from users of our pre­vi­ous 4.0 re­lease. Log­ging is now done di­rect­ly in the DBMS which sim­pli­fies a lot of things for you.

For the full de­tails, see LogCloud Doc­u­men­ta­tion.

Re­moved: RMI trans­ac­tions

No­body uses RMI any more, so we re­moved our RMI trans­ac­tions mod­ule. For trans­ac­tions that span mi­croser­vices: try REST/HTTP in­stead.

Re­moved JmxTrans­ac­tionMan­agerBean

The MBean com.atom­ikos.jmx.trans­ac­tions.JmxTrans­ac­tionMan­agerBean has been re­moved since the new re­cov­ery has re­placed its func­tion­al­i­ty by event log­ging.

Ask your sup­port rep­re­sen­ta­tive for de­tails on how to con­fig­ure event log­ging / mon­i­tor­ing.

Merged trans­ac­tions-jmx-jta into trans­ac­tions-jmx

Th­ese mod­ules have now been merged into one mod­ule / jar.

JMX: show last reap time

The JMX con­trols for our data­source / con­nec­tion fac­to­ry now also show the last reap time.

Avail­able to cus­tomers only. Want to be­come a cus­tomer?

Send me a quote

I have read and ac­cept the pri­va­cy pol­i­cy.

Mes­sage: Please send me a quote for Ex­tremeTrans­ac­tion­s5­dot0 Date: 14 May 2026 - 18:01 Email: !!ad­dress!! Re­mote-Host: 216.73.216.223