Th­ese are the re­lease notes for Ex­tremeTrans­ac­tions 3.9.29

143008: JDBC con­nec­tion proxy: don't keep pend­ing state­ments if they are closed

Our con­nec­tion proxy keeps a list of pend­ing state­ments so they can be closed au­to­mat­i­cal­ly when need­ed. By de­fault, this would also in­clude state­ments that are al­ready closed by the ap­pli­ca­tion. This caus­es need­less mem­o­ry us­age over­head, and has now been fixed: state­ments that were closed by the ap­pli­ca­tion are purged from the list of pend­ing state­ments.

Up­grade to this ver­sion if you have mem­o­ry prob­lems due to long trans­ac­tions with many JDBC state­ments.

WARNING: do NOT up­grade if your JDBC dri­ver is not JDBC 4 com­pli­ant.

140407: Un­nec­es­sary syn­chro­ni­sa­tion over­head in AtomikosNonXADataSourceBean

Re­moved un­nec­es­sary syn­chro­ni­sa­tion over­head to op­ti­mize per­for­mance.

IMPORTANT: this re­lease is a high­ly rec­om­mend­ed fix for your in­stal­la­tion if you are us­ing re­lease 3.7.8 or lat­er. If you don't up­grade then you risk los­ing part of the trans­ac­tion.

140169: XARe­source.com­mit suc­ceeds for roll­back ex­cep­tion dur­ing XARe­source.end

Dur­ing an ear­li­er fix for case 102827 in re­lease 3.7.8 (con­nec­tion leak for er­rors dur­ing XARe­source.end), we dis­abled throw­ing ex­cep­tions orig­i­nat­ing from XARe­source.end, as­sum­ing that XARe­source.pre­pare would sub­se­quent­ly refuse to pre­pare or com­mit the Xid in ques­tion. It turns out that there was a prob­lem with this as­sump­tion and the way it was im­ple­ment­ed in the code, which caused this is­sue. This has been fixed, and of course we've added a test to pre­vent fu­ture re­gres­sion.

139936: Me­mory leak in AtomikosJm­sCon­nec­tionProxy

There was a bug in re­mov­ing ob­so­lete ses­sions, caused by in­com­pat­i­bil­i­ty of the equals method and dy­nam­ic prox­ies. This has now been fixed.