Ex­tremeTrans­ac­tions 6.0.119

Re­lease notes for 6.0.119

Ex­tremeTrans­ac­tions 6.0.119 hard­ens crash re­cov­ery (a sib­ling-branch atom­ic­i­ty resid­ual is closed; a failed or dan­ger­ous­ly-late com­mit-log write is now treat­ed as a heuris­tic haz­ard rather than an in­cor­rect roll­back) and fix­es JMS con­nec­tion-pool reuse of a con­nec­tion bro­ken asyn­chro­nous­ly (for ex­am­ple IBM MQ). It also adds LogCloud re­cov­ery-ac­tion au­dit­ing with a read-only view­er, and cor­rects cross-ser­vice re­cov­ery and Spring Boot 3.4 con­fig­u­ra­tion. It is a drop-in re­place­ment for ear­li­er 6.0.x re­leas­es.

LogCloud re­cov­ery ob­serv­abil­i­ty

Ex­tremeTrans­ac­tions now records and sur­faces re­cov­ery ac­tiv­i­ty in LogCloud: suc­cess­ful re­cov­ery ac­tions and heuris­tic out­comes are writ­ten to LogCloud ta­bles (with a con­fig­urable re­ten­tion lim­it) and are brows­able in a new read-only web view­er, in­clud­ing sub­scrip­tion and li­cense in­for­ma­tion per re­cov­ery do­main.

Fea­ture230452

Suc­cess­ful re­cov­ery ac­tions are logged to a new LogCloud au­dit ta­ble

De­scrip­tion

Suc­cess­ful re­cov­ery ac­tions - pre­sumed aborts and re­play com­mits - are record­ed in a new LogCloud ta­ble, so re­cov­ery out­comes can be cor­re­lat­ed across a trans­ac­tion's branch­es rather than ob­served one event at a time.

Tech­ni­cal de­tails

Dur­ing re­cov­ery, XARe­cov­eryMan­ag­er records each com­plet­ed ac­tion (pre­sumed abort, re­play com­mit) in a new LogCloud data­base ta­ble, along­side the per-oc­cur­rence events that al­ready ex­ist­ed. This is an Ex­tremeTrans­ac­tions (LogCloud) fea­ture and is ac­tive when LogCloud is con­fig­ured.

Changes im­pact­ing client API

None.

Fea­ture230474

New read-only web view­er for the LogCloud ta­bles

De­scrip­tion

A read-only web view­er brows­es the LogCloud ta­bles - in­clud­ing the re­cov­ery-ac­tion and heuris­tic-out­come his­to­ry - us­ing key­set (cur­sor) pag­i­na­tion.

Tech­ni­cal de­tails

A new op­tion­al por­tal com­po­nent (trans­ac­tions-log­cloud-por­tal) serves a read-only UI and query API over the LogCloud data­base, us­ing key­set (cur­sor) pag­i­na­tion rather than off­set pag­ing. It re­turns a clear er­ror when the un­der­ly­ing ta­bles are not present.

Changes im­pact­ing client API

A new, sep­a­rate­ly de­ployed com­po­nent with its own HTTP end­points; it does not change any ex­ist­ing API.

Fea­ture230516

Con­fig­urable re­ten­tion lim­it for the LogCloud re­cov­ery-log ta­bles

De­scrip­tion

A con­fig­urable re­ten­tion lim­it bounds the growth of the re­cov­ery-log ta­bles, so a long-lived de­ploy­ment does not ac­cu­mu­late rows with­out bound.

Tech­ni­cal de­tails

RECOVERY_ACTION_LOG and RECOVERY_HEURISTIC_LOG gain a re­ten­tion-based cleanup sweep. Pre­vi­ous­ly only a per-key retry cap ex­ist­ed and RECOVERY_HEURISTIC_LOG had no bound at all, so a long-lived de­ploy­ment could ac­cu­mu­late rows with­out lim­it.

Changes im­pact­ing client API

Two new con­fig­u­ra­tion prop­er­ties con­trol the sweep: com.atom­ikos.icatch.log­cloud_re­cov­ery_ac­tion_log_re­ten­tion_­days and com.atom­ikos.icatch.log­cloud_re­cov­ery_ac­tion_log_­max_rows.

Fea­ture230548

LogCloud view­er shows sub­scrip­tion and li­cense info per re­cov­ery do­main

De­scrip­tion

The view­er's Sub­scrip­tions screen shows sub­scrip­tion and li­cense in­for­ma­tion (li­censee, ex­piry) per re­cov­ery do­main.

Tech­ni­cal de­tails

The view­er's Sub­scrip­tions screen lists re­cov­ery do­mains with their pub­lished sub­scrip­tion info (li­censee, ex­piry), read with­out en­force­ment via Sub­scrip­tionVer­i­fi­er.read­In­fo() and pub­lished into the LogCloud start­up con­fig­u­ra­tion; a GET /do­mains end­point backs the screen.

Changes im­pact­ing client API

A new GET /do­mains end­point on the por­tal; no ex­ist­ing API changes.

Re­cov­ery de­ci­sion ar­biter

Re­cov­ery now re­solves a rare atom­ic­i­ty edge case con­sis­tent­ly: a de­ci­sion ar­biter records the first de­ci­sion reached for a co­or­di­na­tor so every sib­ling branch fol­lows it. The open-source edi­tion ships an in-mem­o­ry ar­biter; LogCloud adds a durable, cross-node de­ci­sion store.

Fea­ture230638

Re­cov­ery: con­sis­tent de­ci­sions across a trans­ac­tion's sib­ling branch­es

De­scrip­tion

A gener­ic re­cov­ery-de­ci­sion ar­biter records the first de­ci­sion reached for a co­or­di­na­tor and gates the re­play-com­mit / pre­sumed-abort paths on it, so sib­ling branch­es can no longer be de­cid­ed in­con­sis­tent­ly. The open-source edi­tion ships an in-mem­o­ry de­ci­sion store.

Tech­ni­cal de­tails

A gener­ic re­cov­ery-de­ci­sion ar­biter records the first de­ci­sion reached for a co­or­di­na­tor and gates the XARe­cov­eryMan­ag­er re­play-com­mit and pre­sumed-abort paths on it, clos­ing a sin­gle-ac­tor atom­ic­i­ty resid­ual. The open-source edi­tion ships an in-mem­o­ry de­fault de­ci­sion store; the durable, cross-node store is a LogCloud fea­ture (case 230734).

Changes im­pact­ing client API

None.

Fea­ture230734

LogCloud: durable, cross-node re­cov­ery de­ci­sions

De­scrip­tion

A durable Re­cov­eryDe­ci­sionS­tore backed by LogCloud JDBC makes the ar­biter's de­ci­sions durable and con­sis­tent across nodes and restarts, so a stale or restart­ed leader can­not re­verse a de­ci­sion an­oth­er node has record­ed.

Tech­ni­cal de­tails

A durable Re­cov­eryDe­ci­sionS­tore backed by LogCloud JDBC records the first re­cov­ery de­ci­sion per co­or­di­na­tor atom­i­cal­ly (first-writer-wins via a UNIQUE con­straint), with a SafeGC mark-then-sweep re­ten­tion pass and a start­up guard. It plugs into the case-230638 ar­biter through a Ser­viceLoad­er seam. Ex­tremeTrans­ac­tions (LogCloud) only.

Changes im­pact­ing client API

None.

Fea­ture230781

JMS pool: a con­nec­tion bro­ken asyn­chro­nous­ly is no longer reused

De­scrip­tion

A pooled JMS con­nec­tion whose un­der­ly­ing con­nec­tion has bro­ken is no longer hand­ed back out of the pool when the fail­ure was sig­nalled only asyn­chro­nous­ly by the provider (for ex­am­ple IBM MQ MQRC_CONNECTION_BROKEN). This means such a con­nec­tion is now marked er­ro­neous, de­stroyed and re­placed in­stead of reused.

Tech­ni­cal de­tails

Atomikos now reg­is­ters its own javax.jms.Ex­cep­tionLis­ten­er on the phys­i­cal con­nec­tion and marks the pooled con­nec­tion er­ro­neous on an asyn­chro­nous onEx­cep­tion, so bor­row val­i­da­tion re­jects it. Any ap­pli­ca­tion-sup­plied lis­ten­er (for ex­am­ple Spring's Cach­ingCon­nec­tionFac­to­ry) is pre­served and chained un­der Atomikos's, so both ob­serve the break. Pre­vi­ous­ly only a syn­chro­nous JMSEx­cep­tion through a prox­ied call marked the con­nec­tion er­ro­neous.

Changes im­pact­ing client API

None. An ap­pli­ca­tion lis­ten­er set through the pooled con­nec­tion is chained, not re­placed, so setEx­cep­tionLis­ten­er / getEx­cep­tionLis­ten­er be­have as be­fore from the caller's point of view.

Bug218963

Spring Boot 3.4: thread­ed two-phase com­mit can now be con­fig­ured

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

De­scrip­tion

The Spring Boot 3.4 starter now lets you con­fig­ure thread­ed two-phase com­mit. This means the thread­ed2pc prop­er­ty is ap­plied, where be­fore it was silent­ly dropped.

Tech­ni­cal de­tails

The Spring Boot 3.4 prop­er­ty bind­ing was miss­ing the map­ping for thread­ed 2PC; it now maps through to the com.atom­ikos.icatch.thread­ed_2pc trans­ac­tion-man­ag­er prop­er­ty, match­ing the oth­er starters.

Changes im­pact­ing client API

The Spring Boot 3.4 thread­ed2pc prop­er­ty is now ho­n­oured (un­der­ly­ing prop­er­ty com.atom­ikos.icatch.thread­ed_2pc).

Bug228139

LogCloud cross-ser­vice re­cov­ery no longer re­quires a shared tm_u­nique_­name across ser­vices

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

De­scrip­tion

Cross-ser­vice re­cov­ery un­der LogCloud no longer re­quires every ser­vice to share one tm_u­nique_­name. This means a leader re­cov­ers trans­ac­tions across ser­vices cor­rect­ly, in­stead of only its own back­ends.

Tech­ni­cal de­tails

The cross-do­main im­port guard, which re­fused a trans­ac­tion whose re­cov­eryDo­mainName dif­fered from the lo­cal tm_u­nique_­name when LogCloud was ac­tive, is re­laxed to a warn­ing. JDBCRe­cov­eryLog gains an ac­cept­sDo­main check with a sym­met­ric cache.

Changes im­pact­ing client API

None.

Bug230403

Par­ti­tionedCon­nec­tionPool could tran­sient­ly ex­ceed maxPoolSize un­der con­cur­rent growth

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

De­scrip­tion

The par­ti­tioned con­nec­tion pool no longer tran­sient­ly ex­ceeds maxPoolSize un­der con­cur­rent growth. This means the con­fig­ured max­i­mum is re­spect­ed even when sev­er­al threads grow the pool at once.

Tech­ni­cal de­tails

re­serveGrowthSlot() in Par­ti­tionedCon­nec­tionPool was an in­cre­ment-then-check-then-roll­back se­quence, so a brief over­shoot of one con­nec­tion was ob­serv­able un­der high con­cur­ren­cy; the reser­va­tion is now a sin­gle atom­ic step. Sur­faced by a stress vari­ant of the case-216947 pool test.

Changes im­pact­ing client API

None.

Bug230421

A failed com­mit-log write is treat­ed as a heuris­tic haz­ard, not a roll­back

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

De­scrip­tion

A trans­ac­tion whose com­mit-log write fails or times out is now treat­ed as a heuris­tic haz­ard rather than be­ing rolled back. This means an un­cer­tain log write no longer leads to an in­cor­rect roll­back de­ci­sion.

Tech­ni­cal de­tails

Co­or­di­na­torS­tateHan­dler.com­mitFromWithinCall­back() pre­vi­ous­ly caught every Run­timeEx­cep­tion dur­ing the tran­si­tion to COMMITTING and al­ways threw Roll­back­Ex­cep­tion, con­flat­ing a failed/un­cer­tain write with a le­git­i­mate re­cov­ery-dri­ven roll­back. A failed com­mit-log write is now clas­si­fied as a heuris­tic haz­ard. Back­port of case 168377.

Changes im­pact­ing client API

None.

Bug230448

A re­cov­ery-log write that cross­es its dead­line now fails fast

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

De­scrip­tion

A re­cov­ery-log write that cross­es its dead­line dur­ing the data­base in­sert now fails in­stead of re­turn­ing nor­mal­ly. This means a dan­ger­ous­ly late log write is han­dled con­sis­tent­ly, how­ev­er the late­ness is de­tect­ed.

Tech­ni­cal de­tails

JDBCRe­cov­eryLog.write() had two di­ver­gent paths for a dan­ger­ous­ly-late com­mit-log write: a failed/timed-out write threw, but a write that suc­ceed­ed yet crossed the dead­line on the post-in­sert hasEx­pired() check only pub­lished an event and re­turned. Both now throw, so the down­stream heuris­tic-haz­ard han­dling (case 230421) ap­plies uni­form­ly.

Changes im­pact­ing client API

None.

SBOM — run­time de­pen­den­cies are min­i­mal­is­tic

Con­cern­ing se­cu­ri­ty and vul­ner­a­bil­i­ties: the fol­low­ing are the run­time de­pen­den­cies (the SBOM) of our prod­uct. As you can see, the only tran­si­tive third-par­ty de­pen­den­cies are for the Spring Boot in­te­gra­tion mod­ules — be­cause that is the only way to in­te­grate with Spring Boot. All oth­er mod­ules / jars have no third-par­ty run­time de­pen­den­cies what­so­ev­er.

This is com­pile + run­time scope; pro­vid­ed, test and non-prop­a­gat­ing op­tion­al de­pen­den­cies are ex­clud­ed, so it is what your ap­pli­ca­tion ac­tu­al­ly re­ceives. Look up the mod­ule(s) your ap­pli­ca­tion de­pends on.

To re­pro­duce it your­self, run this in a project that de­pends on the Atomikos ar­ti­facts you use (use ex­act­ly this — not a bare de­pen­den­cy:tree, which would also list op­tion­al/pro­vid­ed li­braries you are not giv­en):

mvn dependency:list -DincludeScope=runtime

Mo­d­ules with no third-par­ty run­time de­pen­den­cies

ExtremeTransactionsForMaven
ate
atomikos-util
axt
extreme-transactions
extreme-transactions-jakarta
products
spring-boot2
spring-boot3
spring-boot3.4
spring-boot4
subscription
transactions
transactions-allegrograph
transactions-api
transactions-eclipselink
transactions-essentials
transactions-essentials-jakarta
transactions-hazelcast
transactions-hibernate2
transactions-hibernate3
transactions-hibernate4
transactions-jdbc
transactions-jms
transactions-jmx
transactions-jndi-provider
transactions-jsp
transactions-jta
transactions-logcloud
transactions-logutil
transactions-micrometer
transactions-monitoring
transactions-monitoring-logs
transactions-monitoring-stderr
transactions-opentracing
transactions-osgi
transactions-osgi-axt
transactions-remoting
transactions-remoting-recovery
transactions-spring
transactions-spring-boot-logcloud
transactions-tomcat

Per-mod­ule third-par­ty run­time de­pen­den­cies (opt-in, cus­tomer-cho­sen)

The de­pen­den­cies be­low ap­pear ONLY if you choose to use the cor­re­spond­ing in­te­gra­tion mod­ule. They are the plat­form your ap­pli­ca­tion al­ready runs — you added, say, the Spring Boot starter be­cause you use Spring Boot. Th­ese are your own, cus­tomer-cho­sen de­pen­den­cies: Atomikos does not in­ject any­thing into your in­fra­struc­ture; you opt in by de­pend­ing on the mod­ule.

transactions-spring-boot
  org.springframework.boot:spring-boot:2.3.4.RELEASE
  org.springframework:spring-aop:5.2.9.RELEASE
  org.springframework:spring-beans:5.2.9.RELEASE
  org.springframework:spring-context:5.2.9.RELEASE
  org.springframework:spring-core:5.2.9.RELEASE
  org.springframework:spring-expression:5.2.9.RELEASE
  org.springframework:spring-jcl:5.2.9.RELEASE
  org.springframework:spring-tx:5.2.9.RELEASE

transactions-spring-boot-starter
  org.springframework.boot:spring-boot:2.3.4.RELEASE
  org.springframework:spring-aop:5.2.9.RELEASE
  org.springframework:spring-beans:5.2.9.RELEASE
  org.springframework:spring-context:5.2.9.RELEASE
  org.springframework:spring-core:5.2.9.RELEASE
  org.springframework:spring-expression:5.2.9.RELEASE
  org.springframework:spring-jcl:5.2.9.RELEASE
  org.springframework:spring-tx:5.2.9.RELEASE

transactions-spring-boot3
  jakarta.jms:jakarta.jms-api:3.1.0
  jakarta.transaction:jakarta.transaction-api:2.0.1
  org.springframework.boot:spring-boot:3.0.1
  org.springframework:spring-aop:6.0.3
  org.springframework:spring-beans:6.0.3
  org.springframework:spring-context:6.0.3
  org.springframework:spring-core:6.0.3
  org.springframework:spring-expression:6.0.3
  org.springframework:spring-jcl:6.0.3
  org.springframework:spring-tx:6.0.3

transactions-spring-boot3-starter
  jakarta.jms:jakarta.jms-api:3.1.0
  jakarta.transaction:jakarta.transaction-api:2.0.1
  org.springframework.boot:spring-boot:3.0.1
  org.springframework:spring-aop:6.0.3
  org.springframework:spring-beans:6.0.3
  org.springframework:spring-context:6.0.3
  org.springframework:spring-core:6.0.3
  org.springframework:spring-expression:6.0.3
  org.springframework:spring-jcl:6.0.3
  org.springframework:spring-tx:6.0.3

transactions-spring-boot3.4
  io.micrometer:micrometer-commons:1.12.0
  io.micrometer:micrometer-observation:1.12.0
  jakarta.jms:jakarta.jms-api:3.1.0
  jakarta.transaction:jakarta.transaction-api:2.0.1
  org.springframework.boot:spring-boot:3.2.0
  org.springframework:spring-aop:6.1.1
  org.springframework:spring-beans:6.1.1
  org.springframework:spring-context:6.1.1
  org.springframework:spring-core:6.1.1
  org.springframework:spring-expression:6.1.1
  org.springframework:spring-jcl:6.1.1
  org.springframework:spring-tx:6.1.1

transactions-spring-boot3.4-starter
  io.micrometer:micrometer-commons:1.12.0
  io.micrometer:micrometer-observation:1.12.0
  jakarta.jms:jakarta.jms-api:3.1.0
  jakarta.transaction:jakarta.transaction-api:2.0.1
  org.springframework.boot:spring-boot:3.2.0
  org.springframework:spring-aop:6.1.1
  org.springframework:spring-beans:6.1.1
  org.springframework:spring-context:6.1.1
  org.springframework:spring-core:6.1.1
  org.springframework:spring-expression:6.1.1
  org.springframework:spring-jcl:6.1.1
  org.springframework:spring-tx:6.1.1

transactions-spring-boot4
  ch.qos.logback:logback-classic:1.5.21
  ch.qos.logback:logback-core:1.5.21
  com.zaxxer:HikariCP:7.0.2
  commons-logging:commons-logging:1.3.5
  io.micrometer:micrometer-commons:1.16.0
  io.micrometer:micrometer-observation:1.16.0
  jakarta.annotation:jakarta.annotation-api:3.0.0
  jakarta.jms:jakarta.jms-api:3.1.0
  jakarta.transaction:jakarta.transaction-api:2.0.1
  org.apache.logging.log4j:log4j-api:2.25.2
  org.apache.logging.log4j:log4j-to-slf4j:2.25.2
  org.jspecify:jspecify:1.0.0
  org.slf4j:jul-to-slf4j:2.0.17
  org.slf4j:slf4j-api:2.0.17
  org.springframework.boot:spring-boot-autoconfigure:4.0.0
  org.springframework.boot:spring-boot-data-commons:4.0.0
  org.springframework.boot:spring-boot-data-jdbc:4.0.0
  org.springframework.boot:spring-boot-jdbc:4.0.0
  org.springframework.boot:spring-boot-jms:4.0.0
  org.springframework.boot:spring-boot-persistence:4.0.0
  org.springframework.boot:spring-boot-sql:4.0.0
  org.springframework.boot:spring-boot-starter-data-jdbc:4.0.0
  org.springframework.boot:spring-boot-starter-jdbc:4.0.0
  org.springframework.boot:spring-boot-starter-jms:4.0.0
  org.springframework.boot:spring-boot-starter-logging:4.0.0
  org.springframework.boot:spring-boot-starter:4.0.0
  org.springframework.boot:spring-boot-transaction:4.0.0
  org.springframework.boot:spring-boot:4.0.0
  org.springframework.data:spring-data-commons:4.0.0
  org.springframework.data:spring-data-jdbc:4.0.0
  org.springframework.data:spring-data-relational:4.0.0
  org.springframework:spring-aop:7.0.1
  org.springframework:spring-beans:7.0.0
  org.springframework:spring-context:7.0.1
  org.springframework:spring-core:7.0.0
  org.springframework:spring-expression:7.0.1
  org.springframework:spring-jdbc:7.0.1
  org.springframework:spring-jms:7.0.1
  org.springframework:spring-messaging:7.0.1
  org.springframework:spring-tx:7.0.0
  org.yaml:snakeyaml:2.5

transactions-spring-boot4-starter
  ch.qos.logback:logback-classic:1.5.21
  ch.qos.logback:logback-core:1.5.21
  com.zaxxer:HikariCP:7.0.2
  commons-logging:commons-logging:1.3.5
  io.micrometer:micrometer-commons:1.16.0
  io.micrometer:micrometer-observation:1.16.0
  jakarta.annotation:jakarta.annotation-api:3.0.0
  jakarta.jms:jakarta.jms-api:3.1.0
  jakarta.transaction:jakarta.transaction-api:2.0.1
  org.apache.logging.log4j:log4j-api:2.25.2
  org.apache.logging.log4j:log4j-to-slf4j:2.25.2
  org.jspecify:jspecify:1.0.0
  org.slf4j:jul-to-slf4j:2.0.17
  org.slf4j:slf4j-api:2.0.17
  org.springframework.boot:spring-boot-autoconfigure:4.0.0
  org.springframework.boot:spring-boot-data-commons:4.0.0
  org.springframework.boot:spring-boot-data-jdbc:4.0.0
  org.springframework.boot:spring-boot-jdbc:4.0.0
  org.springframework.boot:spring-boot-jms:4.0.0
  org.springframework.boot:spring-boot-persistence:4.0.0
  org.springframework.boot:spring-boot-sql:4.0.0
  org.springframework.boot:spring-boot-starter-data-jdbc:4.0.0
  org.springframework.boot:spring-boot-starter-jdbc:4.0.0
  org.springframework.boot:spring-boot-starter-jms:4.0.0
  org.springframework.boot:spring-boot-starter-logging:4.0.0
  org.springframework.boot:spring-boot-starter:4.0.0
  org.springframework.boot:spring-boot-transaction:4.0.0
  org.springframework.boot:spring-boot:4.0.0
  org.springframework.data:spring-data-commons:4.0.0
  org.springframework.data:spring-data-jdbc:4.0.0
  org.springframework.data:spring-data-relational:4.0.0
  org.springframework:spring-aop:7.0.1
  org.springframework:spring-beans:7.0.0
  org.springframework:spring-context:7.0.1
  org.springframework:spring-core:7.0.0
  org.springframework:spring-expression:7.0.1
  org.springframework:spring-jdbc:7.0.1
  org.springframework:spring-jms:7.0.1
  org.springframework:spring-messaging:7.0.1
  org.springframework:spring-tx:7.0.0
  org.yaml:snakeyaml:2.5

About Sever­i­ty

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