Quite a big main­te­nance re­lease with lots of im­prove­ments con­cern­ing our new re­cov­ery.

Avail­able to cus­tomers only. Want to be­come a cus­tomer?

Send me a quote

Is­sues with the new re­cov­ery

156968: New re­cov­ery: call re­freshXACon­nec­tion when er­rors dur­ing re­cov­ery

Im­proved han­dling of er­ro­neous con­nec­tions for re­cov­ery: in some con­fig­u­ra­tions the con­nec­tion can be bro­ken, and need­sRe­fresh does not seem to de­tect this - re­sult­ing in re­peat­ed re­cov­ery er­rors on each scan. We now re­fresh the con­nec­tion au­to­mat­i­cal­ly af­ter any re­cov­ery er­ror.

155758: Re­cov­ery: re­fine to bet­ter deal with heuris­tics

Heuris­tic log en­tries are now au­to­mat­i­cal­ly dis­card­ed when all par­tic­i­pant en­tries are ei­ther ter­mi­nat­ed or heuris­tic. Upon dis­card­ing, we gen­er­ate an event to al­low for mon­i­tor­ing in ex­ter­nal tools.

155987: Re­cov­ery: im­prove ter­mi­na­tion for par­ent/sub­trans­ac­tion

Im­proved the house­keep­ing of the log for par­ent/sub­trans­ac­tion sit­u­a­tions.

155986: Re­cov­ery: im­prove getCom­mit­tingPar­tic­i­pants() for sub trans­ac­tions

Sub­trans­ac­tions could be pend­ing in the INDOUBT state while the par­ent trans­ac­tion was logged as COMMITTING. The only cor­rect re­cov­ery for the sub trans­ac­tion is to com­mit, so getCom­mit­tingPar­tic­i­pants() should re­turn the par­tic­i­pants of the sub­tx.

156390: Re­move op­tion: au­to­mat­ic re­source reg­is­tra­tion / Tem­po­raryXATrans­ac­tion­alRe­source

This ex­ot­ic op­tion­al fea­ture was not safe with the new re­cov­ery and also not com­pat­i­ble with the LogCloud.

156249: Re­cov­ery: in­clude name of XARe­source

We now use the uniqueRe­sourceName of each re­source to im­prove the house­keep­ing of pend­ing log records.

155974: Sub­trans­ac­tion re­cov­ery can roll­back when par­ent trans­ac­tion is com­mit­ting

Fixed an is­sue where sub trans­ac­tion roll­back was pos­si­ble dur­ing re­cov­ery, when the par­ent did com­mit.

155982: Log­ging of sub trans­ac­tions with new re­cov­ery does not in­clude su­pe­ri­orCo­or­di­na­torId

Log­ging for sub trans­ac­tions was in­com­plete and did not in­clude the par­ent trans­ac­tion's id. This is now fixed.

156956: Al­low pre­sumed abort of IN_DOUBT sub­trans­ac­tion if its par­ent is HEUR_HAZARD or HEUR_MIXED af­ter ABORTING.

Im­proved re­cov­ery for sub­trans­ac­tions with prob­lem­at­ic par­ent trans­ac­tions.

156967: Pre­sumed abort should work for log en­tries in ABORTING state

Pend­ing log en­tries in the ABORTING state will now also be cleaned up dur­ing re­cov­ery.

156924: Ig­nore non-re­cov­er­able states in check­point

Non-re­cov­er­able states like ABORTING (cre­at­ed dur­ing re­cov­ery) don't have to be logged be­cause they are re­pro­ducible on the next re­cov­ery scan. We now avoid writ­ing such en­tries.

156943: Re­cov­ery with com­mit re­play: also re­turn heuris­tic en­tries where wasCom­mit­ted = true

We now also cor­rect­ly re­cov­er and com­mit IN_DOUBT par­tic­i­pant en­tries when the over­all out­come is some form of heuris­tic.

155797: Race con­di­tions: pre­sumed abort ver­sus OLTP com­mit - lack­ing syn­chro­ni­sa­tion

We found and fixed a race con­di­tion where syn­chro­ni­sa­tion was lack­ing.

156812: Gen­er­ate event for pend­ing COMMITTING/ABORTING log en­tries so the re­source can be added to the con­fig if need­ed

For op­er­a­tional mon­i­tor­ing, we now gen­er­ate a warn­ing event when a re­source may have been re­moved from the con­fig­u­ra­tion while it still had pend­ing trans­ac­tions in the re­cov­ery logs.

Im­prove­ments of the LogCloud

156391: LogCloud: also reg­is­ter Hazel­cast re­source

You can now also use Hazel­cast with the LogCLoud.

156617: LogCloud: sup­port xaProp­er­tyNamesToHide

Sen­si­tive con­nec­tor prop­er­ties are now en­crypt­ed over the wire and on disk.

Hazel­cast is now also sup­port­ed as a LogCloud re­source.

Other

156015: Added new con­fig prop­er­ty with max wait time­out dur­ing shut­down in no-force mode

The new prop­er­ty com.atom­ikos.icatch.de­fault­_­max_wait­_­time_on_shut­down al­lows con­fig­ur­ing the max num­ber if mil­lisec­onds that shut­down will wait when in no-force mode.

156355: Ex­am­ple with Hiber­nate 5

Added a new ex­am­ple with Hiber­nate 5.

156798: Time­out with marked abort: log warn­ing to ex­plain rea­son of NO vote

A time­out of an ac­tive trans­ac­tion will add a Roll­back­On­lyPar­tic­i­pant to make pre­pare fail. How­ev­er, lat­er on in the logs this shows up as a NO vote cryp­tic er­ror that peo­ple didn't un­der­stand. This has now been im­proved.

155988: Race con­di­tion be­tween re­cov­ery / pre­sumed abort and OLTP com­mit: im­prove er­ror mes­sage

When re­cov­ery in­ter­leaved with ap­pli­ca­tion-lev­el com­mit at­tempts, some­times the fol­low­ing cryp­tic mes­sage would be in the logs:
javax.transaction.RollbackException: Error in committing: Existing entry: ABORTING incompatible with new entry: COMMITTING - recovery will clean up in the background

We've changed this to point out that in­ter­me­di­ate re­cov­ery is re­spon­si­ble for this sit­u­a­tion.

156800: Al­low OLTP state tran­si­tions from ABANDONED to TERMINATED and the oth­er way around

We've loos­ened state tran­si­tions a bit to avoid need­less warn­ings in the logs.

Avail­able to cus­tomers only. Want to be­come a cus­tomer?

Send me a quote
RSS

Com­ments

Add a com­ment

Cor­po­rate In­for­ma­tion

Atomikos Cor­po­rate Head­quar­ters
Hove­niersstraat, 39/1, 2800
Meche­len, Bel­gium

Con­tact Us

Copy­right 2026 Atomikos BVBA | Our Pri­va­cy Pol­i­cy
By us­ing this site you agree to our cook­ies. More info. That's Fine