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.

Re­lease notes for Ex­tremeTrans­ac­tions 6.1.116