Ex­tremeTrans­ac­tions 4.0.65

Check out our new high-per­for­mance JDBC pools and more!

94285: Re­fac­tored con­nec­tion pool with con­cur­ren­tCon­nec­tionVal­i­da­tion

Re­fac­tored the con­nec­tion pool: the testQuery is now ex­e­cut­ed out­side of a syn­chro­nised block for bet­ter per­for­mance.

165262: Con­fig­u­ra­tion.shut­down meth­ods should log INFO mes­sage

In-line with INFO log­ging poli­cies, shut­down meth­ods now log an INFO mes­sage.

166914: Con­nec­tionPool.bor­rowCon­nec­tion: move testQuery ex­e­cu­tion out­side of syn­chro­nised block

The testQuery used to be in a syn­chro­nised block, now this is no longer the case thanks to a new pool im­ple­men­ta­tion. This is a port of fix 94285 (com­mer­cial branch) to the com­mu­ni­ty.

166918: Sim­pli­fied lock file hand­ing on Win­dows

Merged https://github.com/atom­ikos/trans­ac­tions-es­sen­tials/pull/5.

166919: Auto-cre­ate all nec­es­sary di­rec­to­ries for log files

Merged https://github.com/atom­ikos/trans­ac­tions-es­sen­tials/pull/9.

166920: Eclipse source bun­dle for this atom­ikos ver­sion

Merged https://github.com/atom­ikos/trans­ac­tions-es­sen­tials/pull/10.

159940: In­ef­fi­cien­cy in con­nec­tion re­cy­cling

A call to bor­rowCon­nec­tion() used to be­come blocked due to one thread en­ter­ing canBeRe­cy­cledForCallingThread() it that then wait­ed for the Ses­sionHan­dleS­tate lock - if in use by an­oth­er con­nec­tion at the same time. We fixed this by mak­ing canBeRe­cy­cledForCallingThread() re­turn­ing false with­out lock­ing.

167171: JMS is­sue on dou­ble open

Fixed a JMS is­sue which was first de­scribed here.

167189: JDBC/JMS con­nec­tors: cre­ate JNDI ref­er­ence only af­ter pool is cre­at­ed

We now cre­ate the JNDI ref­er­ence only af­ter the pool has been cre­at­ed - it does not make sense to ex­pose a faulty pool.

167206: Im­prove log­ging - clar­i­fy "Pre­pare: NO vote"

We've clar­i­fied the er­ror re­port­ing to make it clear­er what hap­pened, and avoid con­fu­sion.

167208: Im­prove log warn­ing for trans­ac­tion time­out mes­sage

We've im­proved the log­ging for time­outs - to avoid con­fu­sion.

167209: Don't re­fresh XARe­source for 1-phase com­mit

We used to re­fresh to XARe­source on con­nec­tiv­i­ty is­sues. Re­fresh­ing made lit­tle sense in case of 1-phase com­mit be­cause there is no pre­pared trans­ac­tion XID in the data­source, mean­ing a dif­fer­ent con­nec­tion would prob­a­bly not know about it.

167220: En­sure that testQuery has no pool over­head

This is one of the best per­for­mance im­prove­ments we ever made: we now en­sure that the (new) pool does not im­pact per­for­mance when set­ting a testQuery. This makes our pools about as fast as non-JTA/XA pools, mean­ing re­li­a­bil­i­ty comes with­out the per­for­mance cost for your ap­pli­ca­tion! (Check our com­mer­cial of­fer­ings if you want even more...)

167530: Re­cov­ery bug: init/check­point does not take the purge de­lay into ac­count

Fixed a bug in the new re­cov­ery where check­points would purge too much.

167532: CachedRe­pos­i­to­ry race con­di­tion: miss­ing syn­chro­ni­sa­tion

Fixed a syn­chro­ni­sa­tion bug that would show up un­der high loads and would lead to in­com­plete check­points.

167358: REST/ACID: Par­tic­i­pan­tA­dapter should im­ple­ment equals to avoid du­pli­cate 2PC to­wards same back­end

Fixed an is­sue with miss­ing equals/hashCode im­ple­men­ta­tions that would break 2-phase com­mit in cer­tain con­di­tions.

167400: New pool: avoid testQuery over­head on con­nec­tion re­cy­cle

We've added a new pool that makes the testQuery more ef­fi­cient. Now, we went even fur­ther and avoid the testQuery over­head on con­nec­tion re­cy­cling. This main­ly makes it faster for trans­ac­tions that do mul­ti­ple SQL state­ments in the same trans­ac­tion.

167418: CleanupPend­ingTrans­ac­tionCon­tex­tFil­ter: also re­set Thread­Lo­cal trans­ac­tion time­out

Thread reuse in Tom­cat used to in­her­it the trans­ac­tion time­out set by a pre­vi­ous re­quest (if any). This could be con­fus­ing so we now re­set the trans­ac­tion time­out be­tween re­quests.

167528: Tune de­fault check­point in­ter­val for ex­tra per­for­mance

The de­fault check­point in­ter­val used to be sub­op­ti­mal for per­for­mance - our com­mer­cial dis­tri­b­u­tion is now tuned in this re­spect.

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­s4­dot0­dot65 Date: 29 May 2026 - 20:02 Email: !!ad­dress!! Re­mote-Host: 216.73.216.244