Ex­tremeTrans­ac­tions 4.0.71

Re­lease notes for the 4.0.71 re­lease...

172566: Im­proved sup­port for maxLife­time en­force­ment

Even though we had a maxLife­time for con­nec­tions in the pool (to avoid fire­wall is­sues), this was only ap­plied to con­nec­tions that were avail­able at the ex­act mo­ment when the pool's main­te­nance thread was do­ing the check­ing. This has now been im­proved: even if a con­nec­tion is not avail­able at the time of check­ing (i.e., in use by the ap­pli­ca­tion) it will to be reused again af­ter its maxLife­time has passed.

172524: Race con­di­tion in Con­nec­tionPoolWithCon­cur­ren­tVal­i­da­tion on de­stroy of pooled con­nec­tion

The new pool had a race con­di­tion be­tween the ap­pli­ca­tion threads and the pool's main­te­nance thread, as fol­lows:

The main­te­nance thread would do the fol­low­ing - with­out the syn­chro­ni­sa­tion of our old­er pool:

1. Loop over all con­nec­tions to check which ones are avail­able.
2. Close (de­stroy) any such avail­able con­nec­tions that it deemed no longer need­ed.

In par­al­lel, the ap­pli­ca­tion threads would be get­ting con­nec­tions from the pool. This means be­tween steps 1 and 2 of the main­te­nance thread, it could hap­pen that a con­nec­tion was got­ten from the pool and sub­se­quent­ly de­stroyed by the main­te­nance thread.

This has now been fixed.

172571: CleanupPend­ingTrans­ac­tionCon­tex­tFil­ter: im­prove be­hav­iour and en­able tog­gling via prop­er­ty

Our servlet fil­ter takes care of clean­ing up any pend­ing trans­ac­tion con­text for ap­pli­ca­tions that don't clean­ly end the trans­ac­tion as­so­ci­a­tion of the call­ing thread. Pre­vi­ous­ly, this hap­pened only when the thread was reused for a lat­er re­quest (via thread pool­ing in the servlet con­tain­er). This can take time, and the re­sult­ing warn­ings are hard to link back to the orig­i­nal re­quest.

This has been im­proved by mak­ing the cleanup also hap­pen di­rect­ly af­ter each re­quest (rather than wait­ing un­til a next re­quest comes in).

Also, per cus­tomer re­quest we've made it pos­si­ble to "dis­able" this fil­ter­ing be­hav­iour if re­quired, by set­ting the prop­er­ty

com.atomikos.icatch.http.filter_requests=false

This can hap­pen ei­ther in the jta.prop­er­ties file, or via a Sys­tem (JVM) prop­er­ty. This way, you can leave the fil­ter in your web ap­pli­ca­tion's web.xml file - which should make life a bit eas­i­er on the op­er­a­tions peo­ple.

169220: Spec­i­fy a time­out for the testQuery

We now reuse the bor­rowCon­nec­tionTime­out val­ue as the time­out for the testQuery - so testQueries don't block in­def­i­nite­ly and the pool's avail­abil­i­ty is im­proved.

172247: AtomikosDataSourceBean: don't log testQuery warn­ing for con­cur­ren­tCon­nec­tionVal­i­da­tion mode

His­tor­i­cal­ly, a testQuery would gen­er­ate warn­ings re­gard­ing per­for­mance. With the new con­cur­rent val­i­da­tion pool, this is of course no longer re­quired.

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­dot71 Date: 30 May 2026 - 02:09 Email: !!ad­dress!! Re­mote-Host: 216.73.216.244