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.

Two time­out-cor­rect­ness im­prove­ments for XA en­list­ment: an opt-in guard that re­fus­es to en­list a re­source on a trans­ac­tion that has al­ready timed out or been marked roll­back-only — in­ter­rupt­ing it be­fore XA START in­stead of fail­ing lat­er at com­mit — and a fix so an al­ready-timed-out co­or­di­na­tor no longer re­sets an en­list­ed re­source's own time­out to the back­end de­fault (which held XA re­sources longer than need­ed). Plus, you can now skip the lega­cy Or­a­cle AQ forceCon­nec­tionIn­toXaMode workaround on spec-com­pli­ant JMS providers and on Or­a­cle AQ 19c and lat­er.

AI can gen­er­ate a trans­ac­tion man­ag­er in min­utes. But can it re­cov­er cor­rect­ly when the co­or­di­na­tor crash­es be­tween pre­pare and com­mit? That's where the real en­gi­neer­ing be­gins.

In mod­ern Java ar­chi­tec­tures, flex­i­bil­i­ty isn’t a lux­u­ry — it’s a re­quire­ment.

We are hap­py to an­nounce our lat­est work.