Ex­tremeTrans­ac­tions 5.0.99

Re­lease notes for 5.0.99

Re­lease notes for 5.0.99

Bug180060

Clar­i­fy warn­ing mes­sage on fail­ing pre­pare

Sever­i­ty

3

Af­fect­ed ver­sions

4.0.x, 5.0.x

De­scrip­tion

You can now eas­i­ly see whether pre­pare fails due to ei­ther a time­out, or due to a re­source-in­ter­nal is­sue.

Tech­ni­cal de­tails

The warn­ing mes­sage in the log files now dis­tin­guish­es be­tween a trans­ac­tion time­out (where you can in­crease your time­out set­tings) and oth­er rea­sons that don't re­quire changes in time­out set­tings.

Changes im­pact­ing client API

None.

Bug189063

Re­duce lock con­tention on the pooled con­nec­tion

Sever­i­ty

4

Af­fect­ed ver­sions

5.0.x

De­scrip­tion

Con­cur­rent con­nec­tion pool re­quests now have less wait­ing on syn­chro­nised code for con­nec­tions that are al­ready in use.

Tech­ni­cal de­tails

The method AtomikosCon­nec­tionProxy.isA­vail­able() has a syn­chro­nised block of code that would be en­tered every time, for every con­cur­rent re­quest and for every con­nec­tion. Now, when the con­nec­tion is al­ready in use we avoid en­ter­ing the locked sec­tion of code.

This leads to low­er con­tention in high load en­vi­ron­ments.

Changes im­pact­ing client API

None.

Bug189264

Also stop a trans­ac­tion's back­ground timer thread when del­e­gat­ing work to re­cov­ery

Sever­i­ty

2

Af­fect­ed ver­sions

5.0.x

De­scrip­tion

When prob­lem­at­ic trans­ac­tion com­mits are giv­en up and del­e­gate to re­cov­ery, we now also stop the trans­ac­tion's back­ground timer thread.

Tech­ni­cal de­tails

Be­fore this change, prob­lem­at­ic com­mits keep on retry­ing in the trans­ac­tion's back­ground thread. This is gen­er­al­ly fine, but at some time the trans­ac­tion man­ag­er gives up and del­e­gates to the back­ground re­cov­ery process. How­ev­er, the trans­ac­tion's back­ground timer thread would stay ac­tive in that case. This has now been fixed.

Changes im­pact­ing client API

None.

Bug189811

Clar­i­fy warn­ing if JMS pooled con­nec­tion can­not be val­i­dat­ed or closed

Sever­i­ty

3

Af­fect­ed ver­sions

5.0.x

De­scrip­tion

Ex­cep­tions when ei­ther test­ing or de­stroy­ing a con­nec­tion in the pool will now clar­i­fy that the con­nec­tion will be re­placed with a new con­nec­tion, so you don't have to wor­ry about hav­ing to do any­thing spe­cial.

Tech­ni­cal de­tails

Be­fore this change, ex­cep­tions dur­ing test­ing and/or de­stroy­ing a pooled con­nec­tion would have a vague mes­sage. With this change, the mes­sage now clar­i­fies that the con­nec­tion will be re­placed with a new one. This means your op­er­a­tions team does not have to won­der what to do.

Changes im­pact­ing client API

None.

Bug189263

Long con­nec­tion pool wait times when us­ing AtomikosNonXADataSourceBean out­side a JTA trans­ac­tion

Sever­i­ty

3

Af­fect­ed ver­sions

5.0.x

De­scrip­tion

In­stances of com.atom­ikos.jdbc.AtomikosNonXADataSourceBean now no­ti­fy wait­ing getCon­nec­tion() re­quests when a con­nec­tion in use with­out a JTA trans­ac­tion is closed (and be­comes el­i­gi­ble for reuse in the pool). This means you will see less fre­quent waits for bor­rowCon­nec­tionTime­out, so you should see short­er re­quest pro­cess­ing de­lays.

Tech­ni­cal de­tails

The class com.atom­ikos.jdbc.in­ter­nal.JtaU­nawareThread­Lo­calCon­nec­tion proxy was not fir­ing the re­quired event to no­ti­fy wait­ing threads when a thread re­turned a con­nec­tion to the con­nec­tion pool. This in op­po­si­tion to class com.atom­ikos.jdbc.in­ter­nal.JtaAwareThread­Lo­calCon­nec­tion that WAS ac­tu­al­ly fir­ing this event. Due to this, when us­ing JtaU­nawareThread­Lo­calCon­nec­tion the wait­ing threads would ex­haust the max­i­mum bor­row time­out in­stead of try­ing to lease con­nec­tion when no­ti­fied. Client would no­tice that await­ing threads al­ways reach the con­fig­ured bor­row time­out re­gard­less an­oth­er thread re­turned a us­able con­nec­tion to the pool.

Changes im­pact­ing client API

None.

Bug189156

Batch­ingMes­sageLis­ten­erCon­tain­er should re­port which con­nec­tionFac­to­ry is set

Sever­i­ty

4

Af­fect­ed ver­sions

5.0.x

De­scrip­tion

In­stances of com.atom­ikos.spring.Batch­ingMes­sageLis­ten­erCon­tain­er re­quire an in­stance of com.atom­ikos.jms.AtomikosCon­nec­tionFac­to­ryBean. If you make a mis­take in your wiring then you can now see what (oth­er) con­nec­tion fac­to­ry class you are try­ing to set.

Tech­ni­cal de­tails

Be­fore, call­ing com.atom­ikos.spring.Batch­ingMes­sageLis­ten­erCon­tain­er.setCon­nec­tionFac­to­ry(con­nec­tionFac­to­ry) with a wrong ar­gu­ment would mere­ly throw an Il­le­galAr­gu­men­tEx­cep­tion. We now added the ac­tu­al class name of the ar­gu­ment to the ex­cep­tion's mes­sage, so de­bug­ging your con­fig­u­ra­tion be­comes eas­i­er.

Changes im­pact­ing client API

None.

Bug189273

Heuris­tic state han­dlers: avoid end­less com­mit retry

Sever­i­ty

3

Af­fect­ed ver­sions

5.0.x

De­scrip­tion

Heuris­tic trans­ac­tion states in your ap­pli­ca­tion no longer lead to in­fi­nite re­tries in the back­ground.

Tech­ni­cal de­tails

Even with com.atom­ikos.icatch.olt­p_­max_re­tries=0, the class­es HeurHazardS­tateHan­dler and HeurHazardS­tateHan­dler would lead to end­less re­tries in the back­ground. This was due to the fact that the dis­pose method in the state han­dler log­ic would not del­e­gate to the un­der­ly­ing Co­or­di­na­torImp in­stance, so the timer thread would stay ac­tive even af­ter things were left for the re­cov­ery process in the back­ground. The timer thread would trig­ger the retry mech­a­nism.

Changes im­pact­ing client API

None.

Bug188918

XaRe­sourceTrans­ac­tion: don't log ERROR when xare­source is null

Sever­i­ty

2

Af­fect­ed ver­sions

5.0.x, 4.0.x

De­scrip­tion

We no longer log an er­ror mes­sage but rather just a warn­ing when XaRe­sourceTrans­ac­tion.com­mit de­tects that there is no XARe­source to use.

Tech­ni­cal de­tails

Without this fix, you could get into sit­u­a­tions like this (which then got logged a LOT due to is­sue 189273 above):

19/11/2020 15:20:43.467 [Atomikos:3321] ERROR com.atomikos.datasource.xa.XAResourceTransaction - XAResourceTransaction: 31302E3235342E3134362E3131302E746D313539353531353037383735393139373038:31302E3235342E3134362E3131302E746D373030333533: no XAResource to commit?

19/11/2020 15:20:43.467 [Atomikos:3321] ERROR com.atomikos.icatch.imp.CommitMessage - Unexpected error in commit
com.atomikos.icatch.HeurHazardException: XAResourceTransaction: 31302E3235342E3134362E3131302E746D313539353531353037383735393139373038:31302E3235342E3134362E3131302E746D373030333533: no XAResource to commit?
        at com.atomikos.datasource.xa.XAResourceTransaction.commit(XAResourceTransaction.java:529)
        at com.atomikos.icatch.imp.CommitMessage.send(CommitMessage.java:52)
        at com.atomikos.icatch.imp.CommitMessage.send(CommitMessage.java:23)
        at com.atomikos.icatch.imp.PropagationMessage.submit(PropagationMessage.java:67)
        at com.atomikos.icatch.imp.Propagator$PropagatorThread.run(Propagator.java:63)
        at com.atomikos.icatch.imp.Propagator.submitPropagationMessage(Propagator.java:42)
        at com.atomikos.icatch.imp.HeurHazardStateHandler.onTimeout(HeurHazardStateHandler.java:71)
        at com.atomikos.icatch.imp.CoordinatorImp.alarm(CoordinatorImp.java:650)
        at com.atomikos.timing.PooledAlarmTimer.notifyListeners(PooledAlarmTimer.java:95)
        at com.atomikos.timing.PooledAlarmTimer.run(PooledAlarmTimer.java:82)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
19/11/2020 15:20:53.468 [Atomikos:3321] ERROR com.atomikos.datasource.xa.XAResourceTransaction - XAResourceTransaction: 31302E3235342E3134362E3131302E746D313539353531353037383735393139373038:31302E3235342E3134362E3131302E746D373030333533: no XAResource to commit?

We have no re­port of how the sys­tem got into this state, but this can hap­pen on rare oc­ca­sions when the orig­i­nal con­nec­tion breaks and a re­fresh can­not be done.

This is now a warn­ing (since re­cov­ery will deal with it in the back­ground) and thanks to the fix for 189273 it will no longer re­peat end­less­ly.

Changes im­pact­ing client API

None.

Bug188763

Even­tPub­lish­er: re­move con­fus­ing warn­ing if no lis­ten­ers reg­is­tered

Sever­i­ty

4

Af­fect­ed ver­sions

5.0.x

De­scrip­tion

We no longer log a warn­ing if a heuris­tic event hap­pens and no event lis­ten­ers were reg­is­tered.

Tech­ni­cal de­tails

Pre­vi­ous­ly, when a heuris­tic trans­ac­tion hap­pened then the event would get logged as a warn­ing in a place where it was out of con­text. This was very con­fus­ing, even for our team. We con­sid­ered this log­ging to be ob­so­lete, since the ab­sence of any event lis­ten­er sig­nals that the ap­pli­ca­tion does not care in the first place.

With this in mind, the warn­ing has been re­moved. Our mon­i­tor­ing ex­ten­sions should be used for aware­ness of such events.

Changes im­pact­ing client API

None.

Fea­ture185294

Add gRPC re­mot­ing sup­port

You could al­ready make trans­ac­tions span http re­mot­ing calls. With this change, you can now also make trans­ac­tions span gRPC calls.

Tech­ni­cal de­tails

You can now ship trans­ac­tion prop­a­ga­tion head­ers along with gRPC calls, so your trans­ac­tion com­mit / roll­back scope can span gRPC dis­trib­uted ap­pli­ca­tions.

Changes im­pact­ing client API

The mod­ule trans­ac­tions-re­mot­ing now has added in­ter­cep­tor for gRPC:

com.atom­ikos.re­mot­ing.grpc.Trans­ac­tionAwareClien­tIn­ter­cep­tor and com.atom­ikos.re­mot­ing.grpc.Trans­ac­tionAwareServerIn­ter­cep­tor

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­dot99 Date: 29 May 2026 - 21:06 Email: !!ad­dress!! Re­mote-Host: 216.73.216.244