Ex­tremeTrans­ac­tions 6.0.118

Re­lease notes for 6.0.118

Two trans­ac­tion-time­out cor­rect­ness im­prove­ments: a fix so a doomed trans­ac­tion reusing the same con­nec­tion is now in­ter­rupt­ed on every sub­se­quent use, not just the first, plus a new opt-in op­tion to bound a REQUIRES_NEW trans­ac­tion's time­out to its sus­pend­ed par­ent's re­main­ing time. Also in­cludes an SLF4J 2.x de­tec­tion fix and a con­nec­tion-pool idle-evic­tion re­gres­sion fix.

Fea­ture229180

In-mem­o­ry / vault-re­solved sub­scrip­tion con­tent for Sub­scrip­tionVer­i­fi­er (no file on disk)

De­scrip­tion

You can now re­solve the Atomikos sub­scrip­tion (li­cense) con­tent in-mem­o­ry at start­up in­stead of only from a file on disk -- for ex­am­ple fetched from a se­crets vault such as Azure Key Vault, HashiCorp Vault, or AWS Se­crets Man­ag­er. This means the sub­scrip­tion prop­er­ties and sig­na­ture no longer have to be per­sist­ed any­where on the serv­er's file sys­tem to sat­is­fy se­cu­ri­ty au­dits or to keep li­cense ma­te­r­i­al out of low­er en­vi­ron­ments.

Tech­ni­cal de­tails

A new Sub­scrip­tionCon­tentProvider SPI lets you reg­is­ter a ful­ly-con­fig­ured provider in­stance via Con­fig­u­ra­tion.setSub­scrip­tionCon­tentProvider(...); at start­up Atomikos calls it to ob­tain the sub­scrip­tion prop­er­ties and sig­na­ture as In­putStream ob­jects, and nev­er in­stan­ti­ates or con­fig­ures the provider it­self -- you con­struct it with your own vault client and cre­den­tials, the same pat­tern as reg­is­ter­ing a cus­tom XADataSource. If no provider is reg­is­tered, res­o­lu­tion falls back to the pre-ex­ist­ing lookup or­der:

1. a reg­is­tered Sub­scrip­tionCon­tentProvider
2. the com.atom­ikos.icatch.sub­scrip­tion_­fold­er file lo­ca­tion
3. the class­path

so with no provider reg­is­tered, be­hav­iour is un­changed. A built-in Base64Sub­scrip­tionCon­tentProvider is also avail­able for cas­es where no cus­tom provider class is need­ed: it reads the sub­scrip­tion prop­er­ties and sig­na­ture as base64-en­cod­ed con­tent from two new sys­tem prop­er­ties, pop­u­lat­ed by your own se­crets tool­ing (e.g. a Ku­ber­netes Se­cret or a Vault agent) be­fore the JVM starts -- this only keeps the li­cense ma­te­r­i­al off the filesys­tem if that base64 val­ue is it­self in­ject­ed at run­time rather than hard­cod­ed into a script or file that is per­sist­ed on disk or in ver­sion con­trol.

Changes im­pact­ing client API

New SPI in­ter­face com.atom­ikos.icatch.con­fig.Sub­scrip­tionCon­tentProvider, reg­is­tered via the new Con­fig­u­ra­tion.setSub­scrip­tionCon­tentProvider(...) and getSub­scrip­tionCon­tentProvider() meth­ods. New sys­tem prop­er­ties com.atom­ikos.icatch.sub­scrip­tion_prop­er­ties_base64 and com.atom­ikos.icatch.sub­scrip­tion_sig­na­ture_base64 ac­ti­vate the built-in Base64Sub­scrip­tionCon­tentProvider. None of this is ac­tive un­less you reg­is­ter a provider or set these prop­er­ties.

Fea­ture229790

Im­prove re­cov­ery-scan ob­serv­abil­i­ty: log Re­playCom­mit/Pre­sumedAbort at INFO, add pre­pared-xid count event

De­scrip­tion

You can now see re­cov­ery-scan out­comes in the logs at INFO lev­el with­out en­abling full trans­ac­tion-trace de­bug log­ging: re­play-com­mit and pre­sumed-abort de­ci­sions are logged at INFO, and a new event re­ports how many pre­pared XIDs a re­source's re­cov­ery scan ac­tu­al­ly re­turned. This means di­ag­nos­ing a slow-to-re­solve in-doubt trans­ac­tion no longer re­quires turn­ing on de­bug log­ging that also cap­tures every nor­mal trans­ac­tion's par­tic­i­pant-com­mit/abort ac­tiv­i­ty.

Tech­ni­cal de­tails

Re­playCom­mitEvent and Pre­sumedAbortEvent, pub­lished by XARe­cov­eryMan­ag­er, are now han­dled by Re­cov­eryMon­i­tor in­stead of Trans­ac­tionTraceMon­i­tor, so they log at INFO in­de­pen­dent­ly of trans­ac­tion-trace de­bug log­ging; the du­pli­cate han­dling pre­vi­ous­ly in Trans­ac­tionTraceMon­i­tor was re­moved. A new Xid­sRe­cov­eredEvent is pub­lished af­ter each re­source's re­cov­ery scan, car­ry­ing counts only: the to­tal num­ber of pre­pared XIDs re­turned by the re­source's xa_re­cov­er() call, how many were rec­og­nized as this trans­ac­tion man­ag­er's own, and how many be­longed to oth­er trans­ac­tion man­agers shar­ing the same re­source man­ag­er. The raw XID list it­self is not ex­posed by this event -- in a busy shared back­end that list can be rou­tine­ly large, so only the bound­ed counts are sur­faced by de­fault.

Changes im­pact­ing client API

Re­playCom­mitEvent and Pre­sumedAbortEvent log­ging moved from com.atom­ikos.mon­i­tor­ing.Trans­ac­tionTraceMon­i­tor to com.atom­ikos.mon­i­tor­ing.Re­cov­eryMon­i­tor, and now logs at INFO rather than only when DEBUG is en­abled on that log­ger. If your log­ging con­fig­u­ra­tion sets lev­els on ei­ther of those two class­es specif­i­cal­ly to see these events, re­view it af­ter up­grad­ing. A new event type, com.atom­ikos.icatch.event.re­cov­ery.Xid­sRe­cov­eredEvent, is pub­lished to reg­is­tered Even­tLis­ten­er im­ple­men­ta­tions.

Fea­ture229806

Re­cov­eryFailedEvent should car­ry the un­der­ly­ing fail­ure cause

De­scrip­tion

You can now see the un­der­ly­ing cause of a re­source re­cov­ery fail­ure di­rect­ly in Re­cov­eryFailedEvent, in­stead of only the af­fect­ed re­source's name. This means a mon­i­tor­ing dash­board sub­scribed to Re­cov­eryFailedEvent can now tell, for ex­am­ple, a re­source-man­ag­er-un­avail­able fail­ure apart from a roll­back fail­ure, with­out cross-ref­er­enc­ing raw log files.

Tech­ni­cal de­tails

XATrans­ac­tion­alRe­source.re­cov­er() now cap­tures the XAEx­cep­tion en­coun­tered dur­ing a re­source's re­cov­ery scan or a heuris­tic-out­come roll­back and pass­es its mes­sage and XA er­ror code through to Re­cov­eryFailedEvent, in­stead of only log­ging and swal­low­ing the ex­cep­tion. The sep­a­rate, cause-less pub­lish of Re­cov­eryFailedEvent pre­vi­ous­ly done by Re­cov­eryDo­mainSer­vice.per­for­mRe­cov­ery() was re­moved, since XATrans­ac­tion­alRe­source.re­cov­er() now pub­lish­es the event it­self with the fail­ure de­tail at­tached.

Changes im­pact­ing client API

Re­cov­eryFailedEvent (com.atom­ikos.icatch.event.re­cov­ery.Re­cov­eryFailedEvent) now car­ries a cause mes­sage and an XA er­ror code in ad­di­tion to the re­source name. Ex­ist­ing con­sumers of the event are un­af­fect­ed but can now read this ex­tra de­tail.

Fea­ture230271

Bound REQUIRES_NEW trans­ac­tion time­out to the sus­pend­ed par­ent's re­main­ing time (opt-in)

De­scrip­tion

You can now cap a REQUIRES_NEW trans­ac­tion's time­out to the re­main­ing time of the trans­ac­tion it sus­pends, so a com­pound busi­ness op­er­a­tion's over­all dead­line is re­spect­ed even across an in­de­pen­dent REQUIRES_NEW sub-step. This is opt-in and off by de­fault: with noth­ing con­fig­ured, a REQUIRES_NEW trans­ac­tion keeps get­ting its own full de­fault time­out, ex­act­ly as be­fore.

Tech­ni­cal de­tails

When en­abled, the trans­ac­tion man­ag­er tracks the most re­cent­ly sus­pend­ed, not-yet-re­sumed trans­ac­tion on the call­ing thread (via sus­pend() and re­sume()). If a new trans­ac­tion be­gins while one is sus­pend­ed -- the REQUIRES_NEW case -- its time­out is capped to that sus­pend­ed trans­ac­tion's live re­main­ing time, re-read at the mo­ment the new trans­ac­tion starts (not a stale snap­shot tak­en when it was sus­pend­ed). The cap only ever re­duces the re­quest­ed time­out, nev­er ex­tends it: if the sus­pend­ed trans­ac­tion has more time left than the new trans­ac­tion's own de­fault, the de­fault is used un­changed. If more than one trans­ac­tion is sus­pend­ed on the same thread (nest­ed REQUIRES_NEW), the most re­cent­ly sus­pend­ed one is used. No ar­ti­fi­cial min­i­mum is ap­plied: if the sus­pend­ed trans­ac­tion is near­ly out of time, the new trans­ac­tion gets a cor­re­spond­ing­ly short time­out rather than a padded one.

Changes im­pact­ing client API

New fea­ture flag com.atom­ikos.icatch.fea­ture.230271, de­fault false (dis­abled) -- must be ex­plic­it­ly en­abled (in jta.prop­er­ties or as a sys­tem prop­er­ty) to ac­ti­vate this be­hav­iour.

Fea­ture216947

Add new pool with col­lec­tions, of which one is "con­nec­tions in use" or "avail­ableCon­nec­tions"

De­scrip­tion

You can now en­able a par­ti­tioned con­nec­tion-pool track­ing strat­e­gy that keeps in-use and avail­able con­nec­tions in sep­a­rate col­lec­tions, re­duc­ing con­tention when bor­row­ing and en­list­ing con­nec­tions un­der con­cur­rent load.

Tech­ni­cal de­tails

A new Par­ti­tionedCon­nec­tionPool im­ple­men­ta­tion (se­lect­ed through a new Con­nec­tionPoolFac­to­ry be­hind the XCon­nec­tionPool in­ter­face, along­side the ex­ist­ing Con­nec­tionPool) tracks avail­able and in-use con­nec­tions in sep­a­rate col­lec­tions, so bor­row re­quests only scan avail­able con­nec­tions and idle-con­nec­tion main­te­nance only re­moves from the avail­able set. This is opt-in via the com.atom­ikos.icatch.fea­ture.216947 flag, which de­faults to false (dis­abled); with the flag left at its de­fault, con­nec­tion pool­ing is un­changed and con­tin­ues to use the ex­ist­ing Con­nec­tionPool im­ple­men­ta­tion.

Changes im­pact­ing client API

None by de­fault. Set­ting the com.atom­ikos.icatch.fea­ture.216947 sys­tem prop­er­ty / jta.prop­er­ties en­try to true switch­es JDBC/JMS con­nec­tion pool­ing to the new Par­ti­tionedCon­nec­tionPool im­ple­men­ta­tion.

Fea­ture227307

Atomikos JTA Time­out Not Im­me­di­ate­ly In­ter­rupt­ing On­go­ing Trans­ac­tions

De­scrip­tion

You can now rely on the doomed-en­list­ment guard (com.atom­ikos.icatch.fea­ture.227307=true) to catch a trans­ac­tion that times out part­way through a se­quence of state­ments on the same, al­ready-en­list­ed con­nec­tion, not only on its first state­ment. This means a long-run­ning trans­ac­tion that reuses one con­nec­tion across mul­ti­ple state­ments is now cor­rect­ly in­ter­rupt­ed at the first use af­ter it times out, not only when it com­mits.

Tech­ni­cal de­tails

The guard in­tro­duced in 6.0.117 checked whether a trans­ac­tion was doomed (timed out or marked roll­back-only) only at the point a re­source was first en­list­ed. If the same con­nec­tion was then reused for sev­er­al se­quen­tial state­ments with­in that trans­ac­tion, lat­er state­ments were not re-checked, so a trans­ac­tion that timed out part­way through would not be in­ter­rupt­ed un­til it reached com­mit. The guard now re-checks doomed sta­tus on every sub­se­quent use of an al­ready-en­list­ed con­nec­tion, not only the first.

Changes im­pact­ing client API

None be­yond the ex­ist­ing com.atom­ikos.icatch.fea­ture.227307 flag in­tro­duced in 6.0.117 (still false by de­fault) -- this is a re­fine­ment to that flag's ex­ist­ing be­hav­iour, not a new ac­ti­va­tion mech­a­nism.

Fea­ture230323

Add named FEATURE_NNNNN con­stants to Con­figProp­er­ties for known opt-in fea­ture flags

De­scrip­tion

You can now ref­er­ence every known opt-in fea­ture flag by name via con­stants on Con­figProp­er­ties (e.g. Con­figProp­er­ties.FEATURE_227307) in­stead of a raw string lit­er­al.

Tech­ni­cal de­tails

Con­figProp­er­ties gained FEATURE_207056, FEATURE_226870, FEATURE_227307, and FEATURE_230271 con­stants for use with getFea­tureFlag(...). This is a pure­ly ad­di­tive con­ve­nience -- ex­ist­ing code pass­ing the raw string id con­tin­ues to work un­changed. A flag that grad­u­ates (its de­fault be­comes per­ma­nent) or is re­tired (its prop­er­ty is re­moved) keeps its con­stant, marked @Dep­re­cat­ed with javadoc ex­plain­ing what hap­pened, rather than hav­ing it delet­ed.

Changes im­pact­ing client API

None re­quired -- ex­ist­ing getFea­tureFlag("NNNNN") calls with a raw string lit­er­al con­tin­ue to work un­changed. New, op­tion­al: Con­figProp­er­ties.FEATURE_207056, FEATURE_226870, FEATURE_227307, FEATURE_230271 con­stants.

Bug228956

Pool main­te­nance churns idle con­nec­tions with­in minPoolSize (199539 re­gres­sion) - re­store the minPoolSize cap on idle evic­tion

Sever­i­ty:	3
Af­fect­ed ver­sion(s):	6.0.x

De­scrip­tion

The con­nec­tion pool no longer clos­es and re­opens its core minPoolSize con­nec­tions on every main­te­nance cy­cle when the pool is oth­er­wise idle. This means an idle pool stays at rest in­stead of con­tin­u­ous­ly de­stroy­ing and recre­at­ing its min­i­mum con­nec­tions, avoid­ing un­nec­es­sary re­con­nect churn and block­ing I/O held un­der the pool's in­ter­nal lock.

Tech­ni­cal de­tails

Con­nec­tionPool.re­moveIdleCon­nec­tion­sIfMinPoolSizeEx­ceed­ed() had lost its minPoolSize cap in an ear­li­er change, so every main­te­nance pass de­stroyed all idle con­nec­tions past maxIdleTime -- in­clud­ing the core minPoolSize ones -- which were then im­me­di­ate­ly recre­at­ed in the same cy­cle. The cap is re­stored: idle con­nec­tions are now evict­ed only above minPoolSize, match­ing the be­hav­iour of the new­er Par­ti­tionedCon­nec­tionPool. Ex­ist­ing con­nec­tion-val­i­da­tion (con­nec­tionVal­i­da­tionIn­ter­val) and maxLife­time set­tings al­ready cov­er stale-con­nec­tion de­tec­tion, so no opt-in flag was need­ed for this fix.

Changes im­pact­ing client API

None.

Bug229746

SLF4J 2.x not de­tect­ed: ob­so­lete Stat­icLog­gerBin­der probe makes Atomikos log­ging silent­ly fall through

Sever­i­ty:	4
Af­fect­ed ver­sion(s):	6.0.x

De­scrip­tion

Atomikos log­ging no longer silent­ly falls through to log4j2, log4j, or java.util.log­ging when SLF4J 2.x is on the class­path. This means SLF4J 2.x users now get their Atomikos log out­put rout­ed through SLF4J as ex­pect­ed, with­out any con­fig­u­ra­tion change.

Tech­ni­cal de­tails

Atomikos de­tect­ed an avail­able SLF4J bind­ing by prob­ing for org.slf4j.impl.Stat­icLog­gerBin­der, a class SLF4J 2.x re­moved in fa­vor of a Ser­viceLoad­er-based mech­a­nism; on SLF4J 2.x that probe failed silent­ly and Atomikos fell back to what­ev­er oth­er log­ging frame­work was present on the class­path. com.atom­ikos.log­ging.Log­gerFac­to­ry now also probes for org.slf4j.spi.SLF4JSer­viceProvider, so both SLF4J 1.7.x (via Stat­icLog­gerBin­der) and 2.x (via SLF4JSer­viceProvider) are de­tect­ed; if nei­ther is present, Atomikos falls back to its ex­ist­ing be­hav­iour un­changed.

Changes im­pact­ing client API

None.

About Sever­i­ty

The sever­i­ty lev­els we use are de­fined in our sup­port terms and con­di­tions.