Blog - Atomikos https://www.atomikos.com/Blog The Atomikos Blog /pub/Main/SitePreferences/atomikos_logo.webp Blog - Atomikos https://www.atomikos.com/Blog en-us Copyright 2026 Atomikos BVBA ExtremeTransactions 6.0.120 https://www.atomikos.com/Blog/ExtremeTransactions6dot0dot120 https://www.atomikos.com/Blog/ExtremeTransactions6dot0dot120?_t=1787317082 Guy Pardon 2026-08-21T14:58:02Z Release notes

A correctness fix for JMS connection pooling: concurrently closing sessions of a pooled connection can no longer deadlock the pool, so a connection that fails asynchronously (for example an IBM MQ connection drop) is reliably detected and replaced.

Bug230921
JMS connection pool could deadlock when sessions are closed concurrently

Severity:2
Affected version(s):6.0.x

Description

A pooled JMS connection no longer deadlocks when two threads concurrently close different sessions of the same connection, so the pool can reliably reclaim and replace that connection instead of leaving a pool thread stuck.

Technical details

Each JMS session proxy holds its own monitor while it closes, and the close path drove the connection's termination - closing the remaining sessions and announcing the connection as available to the pool - from inside that monitor. Two threads each closing a different session could therefore hold their own session monitor while reaching for the other's: a lock-ordering deadlock. The same path was also not atomic between deciding the connection was available and announcing it, so under the same race a connection that had already been handed back out could be announced available a second time and borrowed by two threads at once.

Termination is now single-shot per borrow: a guard taken under the connection's own monitor ensures at most one thread runs the session teardown and the availability announcement, while the announcement itself still runs outside the monitor. Concurrent close is therefore both deadlock-free and free of the double hand-out. The behaviour is always on; there is nothing to configure.

Changes impacting client API

None.

SBOM — runtime dependencies are minimalistic

Concerning security and vulnerabilities: the following are the runtime dependencies (the SBOM) of our product. As you can see, the only transitive third-party dependencies are for the Spring Boot integration modules — because that is the only way to integrate with Spring Boot. All other modules / jars have no third-party runtime dependencies whatsoever.

This is compile + runtime scope; provided, test and non-propagating optional dependencies are excluded, so it is what your application actually receives. Look up the module(s) your application depends on.

To reproduce it yourself, run this in a project that depends on the Atomikos artifacts you use (use exactly this — not a bare dependency:tree, which would also list optional/provided libraries you are not given): 

mvn dependency:list -DincludeScope=runtime

Modules with no third-party runtime dependencies 

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-module third-party runtime dependencies (opt-in, customer-chosen)

The dependencies below appear ONLY if you choose to use the corresponding integration module. They are the platform your application already runs — you added, say, the Spring Boot starter because you use Spring Boot. These are your own, customer-chosen dependencies: Atomikos does not inject anything into your infrastructure; you opt in by depending on the module. 

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

]]> ExtremeTransactions 6.0.119 https://www.atomikos.com/Blog/ExtremeTransactions6dot0dot119 https://www.atomikos.com/Blog/ExtremeTransactions6dot0dot119?_t=1787146722 Guy Pardon 2026-08-19T15:38:42Z Release notes

ExtremeTransactions 6.0.119 hardens crash recovery (a sibling-branch atomicity residual is closed; a failed or dangerously-late commit-log write is now treated as a heuristic hazard rather than an incorrect rollback) and fixes JMS connection-pool reuse of a connection broken asynchronously (for example IBM MQ). It also adds LogCloud recovery-action auditing with a read-only viewer, and corrects cross-service recovery and Spring Boot 3.4 configuration. It is a drop-in replacement for earlier 6.0.x releases.

LogCloud recovery observability

ExtremeTransactions now records and surfaces recovery activity in LogCloud: successful recovery actions and heuristic outcomes are written to LogCloud tables (with a configurable retention limit) and are browsable in a new read-only web viewer, including subscription and license information per recovery domain.

Feature230452
Successful recovery actions are logged to a new LogCloud audit table

Description

Successful recovery actions - presumed aborts and replay commits - are recorded in a new LogCloud table, so recovery outcomes can be correlated across a transaction's branches rather than observed one event at a time.

Technical details

During recovery, XARecoveryManager records each completed action (presumed abort, replay commit) in a new LogCloud database table, alongside the per-occurrence events that already existed. This is an ExtremeTransactions (LogCloud) feature and is active when LogCloud is configured.

Changes impacting client API

None.

Feature230474
New read-only web viewer for the LogCloud tables

Description

A read-only web viewer browses the LogCloud tables - including the recovery-action and heuristic-outcome history - using keyset (cursor) pagination.

Technical details

A new optional portal component (transactions-logcloud-portal) serves a read-only UI and query API over the LogCloud database, using keyset (cursor) pagination rather than offset paging. It returns a clear error when the underlying tables are not present.

Changes impacting client API

A new, separately deployed component with its own HTTP endpoints; it does not change any existing API.

Feature230516
Configurable retention limit for the LogCloud recovery-log tables

Description

A configurable retention limit bounds the growth of the recovery-log tables, so a long-lived deployment does not accumulate rows without bound.

Technical details

RECOVERY_ACTION_LOG and RECOVERY_HEURISTIC_LOG gain a retention-based cleanup sweep. Previously only a per-key retry cap existed and RECOVERY_HEURISTIC_LOG had no bound at all, so a long-lived deployment could accumulate rows without limit.

Changes impacting client API

Two new configuration properties control the sweep: com.atomikos.icatch.logcloud_recovery_action_log_retention_days and com.atomikos.icatch.logcloud_recovery_action_log_max_rows.

Feature230548
LogCloud viewer shows subscription and license info per recovery domain

Description

The viewer's Subscriptions screen shows subscription and license information (licensee, expiry) per recovery domain.

Technical details

The viewer's Subscriptions screen lists recovery domains with their published subscription info (licensee, expiry), read without enforcement via SubscriptionVerifier.readInfo() and published into the LogCloud startup configuration; a GET /domains endpoint backs the screen.

Changes impacting client API

A new GET /domains endpoint on the portal; no existing API changes.

Recovery decision arbiter

Recovery now resolves a rare atomicity edge case consistently: a decision arbiter records the first decision reached for a coordinator so every sibling branch follows it. The open-source edition ships an in-memory arbiter; LogCloud adds a durable, cross-node decision store.

Feature230638
Recovery: consistent decisions across a transaction's sibling branches

Description

A generic recovery-decision arbiter records the first decision reached for a coordinator and gates the replay-commit / presumed-abort paths on it, so sibling branches can no longer be decided inconsistently. The open-source edition ships an in-memory decision store.

Technical details

A generic recovery-decision arbiter records the first decision reached for a coordinator and gates the XARecoveryManager replay-commit and presumed-abort paths on it, closing a single-actor atomicity residual. The open-source edition ships an in-memory default decision store; the durable, cross-node store is a LogCloud feature (case 230734).

Changes impacting client API

None.

Feature230734
LogCloud: durable, cross-node recovery decisions

Description

A durable RecoveryDecisionStore backed by LogCloud JDBC makes the arbiter's decisions durable and consistent across nodes and restarts, so a stale or restarted leader cannot reverse a decision another node has recorded.

Technical details

A durable RecoveryDecisionStore backed by LogCloud JDBC records the first recovery decision per coordinator atomically (first-writer-wins via a UNIQUE constraint), with a SafeGC mark-then-sweep retention pass and a startup guard. It plugs into the case-230638 arbiter through a ServiceLoader seam. ExtremeTransactions (LogCloud) only.

Changes impacting client API

None.

Feature230781
JMS pool: a connection broken asynchronously is no longer reused

Description

A pooled JMS connection whose underlying connection has broken is no longer handed back out of the pool when the failure was signalled only asynchronously by the provider (for example IBM MQ MQRC_CONNECTION_BROKEN). This means such a connection is now marked erroneous, destroyed and replaced instead of reused.

Technical details

Atomikos now registers its own javax.jms.ExceptionListener on the physical connection and marks the pooled connection erroneous on an asynchronous onException, so borrow validation rejects it. Any application-supplied listener (for example Spring's CachingConnectionFactory) is preserved and chained under Atomikos's, so both observe the break. Previously only a synchronous JMSException through a proxied call marked the connection erroneous.

Changes impacting client API

None. An application listener set through the pooled connection is chained, not replaced, so setExceptionListener / getExceptionListener behave as before from the caller's point of view.

Bug218963
Spring Boot 3.4: threaded two-phase commit can now be configured

Severity:3
Affected version(s):6.0.x

Description

The Spring Boot 3.4 starter now lets you configure threaded two-phase commit. This means the threaded2pc property is applied, where before it was silently dropped.

Technical details

The Spring Boot 3.4 property binding was missing the mapping for threaded 2PC; it now maps through to the com.atomikos.icatch.threaded_2pc transaction-manager property, matching the other starters.

Changes impacting client API

The Spring Boot 3.4 threaded2pc property is now honoured (underlying property com.atomikos.icatch.threaded_2pc).

Bug228139
LogCloud cross-service recovery no longer requires a shared tm_unique_name across services

Severity:2
Affected version(s):6.0.x

Description

Cross-service recovery under LogCloud no longer requires every service to share one tm_unique_name. This means a leader recovers transactions across services correctly, instead of only its own backends.

Technical details

The cross-domain import guard, which refused a transaction whose recoveryDomainName differed from the local tm_unique_name when LogCloud was active, is relaxed to a warning. JDBCRecoveryLog gains an acceptsDomain check with a symmetric cache.

Changes impacting client API

None.

Bug230403
PartitionedConnectionPool could transiently exceed maxPoolSize under concurrent growth

Severity:3
Affected version(s):6.0.x

Description

The partitioned connection pool no longer transiently exceeds maxPoolSize under concurrent growth. This means the configured maximum is respected even when several threads grow the pool at once.

Technical details

reserveGrowthSlot() in PartitionedConnectionPool was an increment-then-check-then-rollback sequence, so a brief overshoot of one connection was observable under high concurrency; the reservation is now a single atomic step. Surfaced by a stress variant of the case-216947 pool test.

Changes impacting client API

None.

Bug230421
A failed commit-log write is treated as a heuristic hazard, not a rollback

Severity:2
Affected version(s):6.0.x

Description

A transaction whose commit-log write fails or times out is now treated as a heuristic hazard rather than being rolled back. This means an uncertain log write no longer leads to an incorrect rollback decision.

Technical details

CoordinatorStateHandler.commitFromWithinCallback() previously caught every RuntimeException during the transition to COMMITTING and always threw RollbackException, conflating a failed/uncertain write with a legitimate recovery-driven rollback. A failed commit-log write is now classified as a heuristic hazard. Backport of case 168377.

Changes impacting client API

None.

Bug230448
A recovery-log write that crosses its deadline now fails fast

Severity:2
Affected version(s):6.0.x

Description

A recovery-log write that crosses its deadline during the database insert now fails instead of returning normally. This means a dangerously late log write is handled consistently, however the lateness is detected.

Technical details

JDBCRecoveryLog.write() had two divergent paths for a dangerously-late commit-log write: a failed/timed-out write threw, but a write that succeeded yet crossed the deadline on the post-insert hasExpired() check only published an event and returned. Both now throw, so the downstream heuristic-hazard handling (case 230421) applies uniformly.

Changes impacting client API

None.

SBOM — runtime dependencies are minimalistic

Concerning security and vulnerabilities: the following are the runtime dependencies (the SBOM) of our product. As you can see, the only transitive third-party dependencies are for the Spring Boot integration modules — because that is the only way to integrate with Spring Boot. All other modules / jars have no third-party runtime dependencies whatsoever.

This is compile + runtime scope; provided, test and non-propagating optional dependencies are excluded, so it is what your application actually receives. Look up the module(s) your application depends on.

To reproduce it yourself, run this in a project that depends on the Atomikos artifacts you use (use exactly this — not a bare dependency:tree, which would also list optional/provided libraries you are not given): 

mvn dependency:list -DincludeScope=runtime

Modules with no third-party runtime dependencies 

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-module third-party runtime dependencies (opt-in, customer-chosen)

The dependencies below appear ONLY if you choose to use the corresponding integration module. They are the platform your application already runs — you added, say, the Spring Boot starter because you use Spring Boot. These are your own, customer-chosen dependencies: Atomikos does not inject anything into your infrastructure; you opt in by depending on the module. 

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

]]> ExtremeTransactions 6.0.118 https://www.atomikos.com/Blog/ExtremeTransactions6dot0dot118 https://www.atomikos.com/Blog/ExtremeTransactions6dot0dot118?_t=1785918804 Guy Pardon 2026-08-05T10:33:24Z Release notes

Two transaction-timeout correctness improvements: a fix so a doomed transaction reusing the same connection is now interrupted on every subsequent use, not just the first, plus a new opt-in option to bound a REQUIRES_NEW transaction's timeout to its suspended parent's remaining time. Also includes an SLF4J 2.x detection fix and a connection-pool idle-eviction regression fix.

Feature229180
In-memory / vault-resolved subscription content for SubscriptionVerifier (no file on disk)

Description

You can now resolve the Atomikos subscription (license) content in-memory at startup instead of only from a file on disk -- for example fetched from a secrets vault such as Azure Key Vault, HashiCorp Vault, or AWS Secrets Manager. This means the subscription properties and signature no longer have to be persisted anywhere on the server's file system to satisfy security audits or to keep license material out of lower environments.

Technical details

A new SubscriptionContentProvider SPI lets you register a fully-configured provider instance via Configuration.setSubscriptionContentProvider(...); at startup Atomikos calls it to obtain the subscription properties and signature as InputStream objects, and never instantiates or configures the provider itself -- you construct it with your own vault client and credentials, the same pattern as registering a custom XADataSource. If no provider is registered, resolution falls back to the pre-existing lookup order:
  1. a registered SubscriptionContentProvider
  2. the com.atomikos.icatch.subscription_folder file location
  3. the classpath
so with no provider registered, behaviour is unchanged. A built-in Base64SubscriptionContentProvider is also available for cases where no custom provider class is needed: it reads the subscription properties and signature as base64-encoded content from two new system properties, populated by your own secrets tooling (e.g. a Kubernetes Secret or a Vault agent) before the JVM starts -- this only keeps the license material off the filesystem if that base64 value is itself injected at runtime rather than hardcoded into a script or file that is persisted on disk or in version control.

Changes impacting client API

New SPI interface com.atomikos.icatch.config.SubscriptionContentProvider, registered via the new Configuration.setSubscriptionContentProvider(...) and getSubscriptionContentProvider() methods. New system properties com.atomikos.icatch.subscription_properties_base64 and com.atomikos.icatch.subscription_signature_base64 activate the built-in Base64SubscriptionContentProvider. None of this is active unless you register a provider or set these properties.

Feature229790
Improve recovery-scan observability: log ReplayCommit/PresumedAbort at INFO, add prepared-xid count event

Description

You can now see recovery-scan outcomes in the logs at INFO level without enabling full transaction-trace debug logging: replay-commit and presumed-abort decisions are logged at INFO, and a new event reports how many prepared XIDs a resource's recovery scan actually returned. This means diagnosing a slow-to-resolve in-doubt transaction no longer requires turning on debug logging that also captures every normal transaction's participant-commit/abort activity.

Technical details

ReplayCommitEvent and PresumedAbortEvent, published by XARecoveryManager, are now handled by RecoveryMonitor instead of TransactionTraceMonitor, so they log at INFO independently of transaction-trace debug logging; the duplicate handling previously in TransactionTraceMonitor was removed. A new XidsRecoveredEvent is published after each resource's recovery scan, carrying counts only: the total number of prepared XIDs returned by the resource's xa_recover() call, how many were recognized as this transaction manager's own, and how many belonged to other transaction managers sharing the same resource manager. The raw XID list itself is not exposed by this event -- in a busy shared backend that list can be routinely large, so only the bounded counts are surfaced by default.

Changes impacting client API

ReplayCommitEvent and PresumedAbortEvent logging moved from com.atomikos.monitoring.TransactionTraceMonitor to com.atomikos.monitoring.RecoveryMonitor, and now logs at INFO rather than only when DEBUG is enabled on that logger. If your logging configuration sets levels on either of those two classes specifically to see these events, review it after upgrading. A new event type, com.atomikos.icatch.event.recovery.XidsRecoveredEvent, is published to registered EventListener implementations.

Feature229806
RecoveryFailedEvent should carry the underlying failure cause

Description

You can now see the underlying cause of a resource recovery failure directly in RecoveryFailedEvent, instead of only the affected resource's name. This means a monitoring dashboard subscribed to RecoveryFailedEvent can now tell, for example, a resource-manager-unavailable failure apart from a rollback failure, without cross-referencing raw log files.

Technical details

XATransactionalResource.recover() now captures the XAException encountered during a resource's recovery scan or a heuristic-outcome rollback and passes its message and XA error code through to RecoveryFailedEvent, instead of only logging and swallowing the exception. The separate, cause-less publish of RecoveryFailedEvent previously done by RecoveryDomainService.performRecovery() was removed, since XATransactionalResource.recover() now publishes the event itself with the failure detail attached.

Changes impacting client API

RecoveryFailedEvent (com.atomikos.icatch.event.recovery.RecoveryFailedEvent) now carries a cause message and an XA error code in addition to the resource name. Existing consumers of the event are unaffected but can now read this extra detail.

Feature230271
Bound REQUIRES_NEW transaction timeout to the suspended parent's remaining time (opt-in)

Description

You can now cap a REQUIRES_NEW transaction's timeout to the remaining time of the transaction it suspends, so a compound business operation's overall deadline is respected even across an independent REQUIRES_NEW sub-step. This is opt-in and off by default: with nothing configured, a REQUIRES_NEW transaction keeps getting its own full default timeout, exactly as before.

Technical details

When enabled, the transaction manager tracks the most recently suspended, not-yet-resumed transaction on the calling thread (via suspend() and resume()). If a new transaction begins while one is suspended -- the REQUIRES_NEW case -- its timeout is capped to that suspended transaction's live remaining time, re-read at the moment the new transaction starts (not a stale snapshot taken when it was suspended). The cap only ever reduces the requested timeout, never extends it: if the suspended transaction has more time left than the new transaction's own default, the default is used unchanged. If more than one transaction is suspended on the same thread (nested REQUIRES_NEW), the most recently suspended one is used. No artificial minimum is applied: if the suspended transaction is nearly out of time, the new transaction gets a correspondingly short timeout rather than a padded one.

Changes impacting client API

New feature flag com.atomikos.icatch.feature.230271, default false (disabled) -- must be explicitly enabled (in jta.properties or as a system property) to activate this behaviour.

Feature216947
Add new pool with collections, of which one is "connections in use" or "availableConnections"

Description

You can now enable a partitioned connection-pool tracking strategy that keeps in-use and available connections in separate collections, reducing contention when borrowing and enlisting connections under concurrent load.

Technical details

A new PartitionedConnectionPool implementation (selected through a new ConnectionPoolFactory behind the XConnectionPool interface, alongside the existing ConnectionPool) tracks available and in-use connections in separate collections, so borrow requests only scan available connections and idle-connection maintenance only removes from the available set. This is opt-in via the com.atomikos.icatch.feature.216947 flag, which defaults to false (disabled); with the flag left at its default, connection pooling is unchanged and continues to use the existing ConnectionPool implementation.

Changes impacting client API

None by default. Setting the com.atomikos.icatch.feature.216947 system property / jta.properties entry to true switches JDBC/JMS connection pooling to the new PartitionedConnectionPool implementation.

Feature227307
Atomikos JTA Timeout Not Immediately Interrupting Ongoing Transactions

Description

You can now rely on the doomed-enlistment guard (com.atomikos.icatch.feature.227307=true) to catch a transaction that times out partway through a sequence of statements on the same, already-enlisted connection, not only on its first statement. This means a long-running transaction that reuses one connection across multiple statements is now correctly interrupted at the first use after it times out, not only when it commits.

Technical details

The guard introduced in 6.0.117 checked whether a transaction was doomed (timed out or marked rollback-only) only at the point a resource was first enlisted. If the same connection was then reused for several sequential statements within that transaction, later statements were not re-checked, so a transaction that timed out partway through would not be interrupted until it reached commit. The guard now re-checks doomed status on every subsequent use of an already-enlisted connection, not only the first.

Changes impacting client API

None beyond the existing com.atomikos.icatch.feature.227307 flag introduced in 6.0.117 (still false by default) -- this is a refinement to that flag's existing behaviour, not a new activation mechanism.

Feature230323
Add named FEATURE_NNNNN constants to ConfigProperties for known opt-in feature flags

Description

You can now reference every known opt-in feature flag by name via constants on ConfigProperties (e.g. ConfigProperties.FEATURE_227307) instead of a raw string literal.

Technical details

ConfigProperties gained FEATURE_207056, FEATURE_226870, FEATURE_227307, and FEATURE_230271 constants for use with getFeatureFlag(...). This is a purely additive convenience -- existing code passing the raw string id continues to work unchanged. A flag that graduates (its default becomes permanent) or is retired (its property is removed) keeps its constant, marked @Deprecated with javadoc explaining what happened, rather than having it deleted.

Changes impacting client API

None required -- existing getFeatureFlag("NNNNN") calls with a raw string literal continue to work unchanged. New, optional: ConfigProperties.FEATURE_207056, FEATURE_226870, FEATURE_227307, FEATURE_230271 constants.

Bug228956
Pool maintenance churns idle connections within minPoolSize (199539 regression) - restore the minPoolSize cap on idle eviction

Severity:3
Affected version(s):6.0.x

Description

The connection pool no longer closes and reopens its core minPoolSize connections on every maintenance cycle when the pool is otherwise idle. This means an idle pool stays at rest instead of continuously destroying and recreating its minimum connections, avoiding unnecessary reconnect churn and blocking I/O held under the pool's internal lock.

Technical details

ConnectionPool.removeIdleConnectionsIfMinPoolSizeExceeded() had lost its minPoolSize cap in an earlier change, so every maintenance pass destroyed all idle connections past maxIdleTime -- including the core minPoolSize ones -- which were then immediately recreated in the same cycle. The cap is restored: idle connections are now evicted only above minPoolSize, matching the behaviour of the newer PartitionedConnectionPool. Existing connection-validation (connectionValidationInterval) and maxLifetime settings already cover stale-connection detection, so no opt-in flag was needed for this fix.

Changes impacting client API

None.

Bug229746
SLF4J 2.x not detected: obsolete StaticLoggerBinder probe makes Atomikos logging silently fall through

Severity:4
Affected version(s):6.0.x

Description

Atomikos logging no longer silently falls through to log4j2, log4j, or java.util.logging when SLF4J 2.x is on the classpath. This means SLF4J 2.x users now get their Atomikos log output routed through SLF4J as expected, without any configuration change.

Technical details

Atomikos detected an available SLF4J binding by probing for org.slf4j.impl.StaticLoggerBinder, a class SLF4J 2.x removed in favor of a ServiceLoader-based mechanism; on SLF4J 2.x that probe failed silently and Atomikos fell back to whatever other logging framework was present on the classpath. com.atomikos.logging.LoggerFactory now also probes for org.slf4j.spi.SLF4JServiceProvider, so both SLF4J 1.7.x (via StaticLoggerBinder) and 2.x (via SLF4JServiceProvider) are detected; if neither is present, Atomikos falls back to its existing behaviour unchanged.

Changes impacting client API

None.

]]> TransactionsEssentials 6.0.1 https://www.atomikos.com/Blog/TransactionsEssentials6dot0dot1 https://www.atomikos.com/Blog/TransactionsEssentials6dot0dot1?_t=1785915584 Guy Pardon 2026-08-05T09:39:44Z Release notes

We are happy to announce our latest work.

CORE IMPROVEMENTS: A SIMPLER AND SAFER (AND DOCUMENTED) CONCURRENCY MODEL

This release includes a optional safer threading and concurrency model for the core engine and performance improvements that come with it. The following 2 improvements all contribute to this goal, and are activated / disabled together - via the following feature flag: 

com.atomikos.icatch.feature.207056=true

Feature207056
New designs for TransactionService and CompositeTransactionManager implementations

The new concurrency model is implemented by 2 new core classes:

  • DefaultTransactionService
  • DefaultCompositeTransactionManager

Feature205830
Performance with concurrent maps

The new core classes also use concurrent hashmaps for increased performance, as outlined in this contribution on GitHub.

CORE IMPROVEMENTS: CORE (SUB) TRANSACTION SUPPORT

Bug207055
Bug in timeout/rollback of local sub transaction followed by commit of its parent

Severity:4
Affected version(s):5.0.x, 6.0.x

Description

We now check for timeout of a local sub transaction when the parent transaction commits.

Technical details

Before this fix, a sub transaction could timeout but this would not block prepare of the parent transaction, leading to unnecessary prepare work and log warnings.

We now check for timeout and fail early when prepare is attempted.

Changes impacting client API

None.

Bug209259
Improve thread-safety of CheckedExportingTransactionManager

Severity:2
Affected version(s):6.0.x

See the full details on GitHub

CONNECTION POOL IMPROVEMENTS

Feature223216
Add support for non-pooled (one-off) connection use

You can now use our JTA/XA connections with your own connection pools.

Technical details

Our JTA/XA connection proxies would not work with external pools. This should now be possible.

Based on a contribution from Open J Proxy (OJP) - an open source database proxy that supports distributed transactions.

Courtesy of the Open J Proxy team - thanks for contributing!

Also see the full details on GitHub.

Changes impacting client API

None, except using your own pools if you like, by using AtomikosNonPoolingDataSourceBean as the datasource.

Bug208965
Bug in borrowing connection: make waiting for available connections fair(er)

Severity:3
Affected version(s):6.0.x

Description

We now avoid that a growing pool's connections are "hijacked" by threads whose requests came in later than the waiting thread.

Technical details

The details are explained on GitHub.

Changes impacting client API

None.

INTEGRATION IMPROVEMENTS

Feature222983
Add Spring Boot 4 starter

You can now use Atomikos with Spring Boot 4

Changes impacting client API

Add the following dependency to your pom in order to use this starter:

   <dependency>
     <groupId>com.atomikos</groupId>
     <artifactId>transactions-spring-boot4-starter</artifactId>
     <version>...</version>
   </dependency>

Feature211078
Add Spring Boot 3.4 starter

You can now use Atomikos with Spring Boot 3.4

Changes impacting client API

Add the following dependency to your pom in order to use this starter:

   <dependency>
     <groupId>com.atomikos</groupId>
     <artifactId>transactions-spring-boot3.4-starter</artifactId>
     <version>...</version>
   </dependency>

Feature207758
Add Hibernate 7 example

You can now use our Hibernate 7 example for inspiration of your project.

Feature201715
Add JakartaEE example

You can now check a basic JakartaEE example.

Technical details

The 6.0 release line added support for JakartaEE, but without examples so far.

We have now added some.

Changes impacting client API

None.

Feature203242
Retry acquiring log file lock on startup

We now retry obtaining a file lock on startup.

Technical details

See the full details on GitHub.

Changes impacting client API

None.

Bug202466
Interposed Synchronisation not called on regular rollback

Severity:4
Affected version(s):6.0.x

Description

Interposed synchronisation instances are now also called on regular rollback.

Technical details

For details, see the original report on GitHub.

Changes impacting client API

None.

Bug209260
Move AtomikosSQLException to public package

Severity:4
Affected version(s):6.0.x

Description

Our AtomikosSQLException is now in the public package of module transactions-jdbc.

Technical details

This exception should not be in the "internal" package - for integration with OSGi this is the best solution. See the full details on GitHub.

Changes impacting client API

We don't expect applications to literally catch this specific exception so the impact should be none. If you do catch this exception in your code then you will have to change the import from com.atomikos.jdbc.internal to com.atomikos.jdbc.

Bug201646
Spring Boot 2 starter: use jta and jms versions of Spring Boot's POM for the starter project

Severity:4
Affected version(s):6.0.x

Description

We (and you) now use the jta and jms versions of Spring Boot's POM for the starter project.

Technical details

The JTA and JMS version dependencies are now aligned with Spring Boot.

We did this already for later Spring Boot integrations, but not yet for Spring Boot 2.

Changes impacting client API

None.

BugINTERNAL
Use h2 version compatible with latest hibernate (6) version

Severity:4
Affected version(s):6.0.x

Description

We now use a more recent h2 version.

Technical details

The pom of the Hibernate 6 examples project has been updated to use a better suitable h2 version.

Changes impacting client API

None.

Severity:4
Affected version(s):6.0.x

Description

Cleaned up the pom file for transactions-eclipselink.

Technical details

The pom file used to reference an extra repository - but it turns out this was not needed with some minor tweaks in the pom.

Changes impacting client API

None.

BugINTERNAL
OSGi service name version is outdated

Severity:4
Affected version(s):6.0.x

Description

The OSGi service name now has the correct version.

MISCELLANEOUS

FeatureINTERNAL
Add support for feature flags in the configuration properties

Features can now be enabled/disabled via feature flag support in the configuration properties:

com.atomikos.icatch.feature.<ID>=...

It can be set to true or false, and helps us with feature flags for risky code changes so we can always fallback to the previous behaviour.

Bug202474
Improve message when transaction was marked for rollback-only

Severity:3
Affected version(s):5.0.x, 6.0.x

Description

You now get a descriptive message that signals rollback-only instead of suggesting a timeout.

Technical details

The customer report is included with the full details below:

some of our applications occasionally log Exceptions like this during execution:

WARN  c.a.j.internal.AtomikosSQLException - The transaction has timed out - try increasing the timeout if needed
WARN  c.a.j.i.AtomikosJdbcConnectionProxy - Error enlisting in transaction - connection might be broken? Please check the logs for more information...

com.atomikos.jdbc.internal.AtomikosSQLException: The transaction has timed out - try increasing the timeout if needed
        at com.atomikos.jdbc.internal.AtomikosSQLException.throwAtomikosSQLException(AtomikosSQLException.java:29)
        at com.atomikos.jdbc.internal.AtomikosSQLException.throwAtomikosSQLException(AtomikosSQLException.java:40)
        at com.atomikos.jdbc.internal.AtomikosJdbcConnectionProxy.enlist(AtomikosJdbcConnectionProxy.java:97)
        at com.atomikos.jdbc.internal.AtomikosJdbcConnectionProxy.updateTransactionContext(AtomikosJdbcConnectionProxy.java:61)
        at com.atomikos.jdbc.internal.AbstractJdbcConnectionProxy.prepareStatement(AbstractJdbcConnectionProxy.java:64)

At first glance, developers thought of an transaction timeout problem, trying to increase the tx-timeout. But in this, timeout increasing did not help.  The reason for this exception was previous SQLException which went through a Spring @Transactional  method, marking the actual Transaction ‚rollback-only‘.

Changes impacting client API

Clearer reports in the log.

Bug207146
Avoid keeping the same open JDBC statements multiple times

Severity:3
Affected version(s):6.0.x

Description

We now avoid adding the same statement many times to the collection of open statements.

Technical details

We keep a collection of open JDBC statements so they can be closed when the JDBC connection is closed.

Our AbstractJdbcConnectionProxy class used to add a same statement multiple times to the collection of open statements and could lead to high memory consumption over time. This was fixed.

Changes impacting client API

None.

Bug207950
Unnecessary XA refresh on closing resource

Severity:3
Affected version(s):6.0.x

Description

We now avoid useless calls to the XAResource on close.

Technical details

Closing a resource would also remove it from the Configuration like this:

    public static RecoverableResource removeResource ( String name )
    {
        RecoverableResource ret = null;
        if ( name != null ) {
              ret = (RecoverableResource) resources_.remove ( name );
              if ( ret != null ) resourceList_.remove ( ret );

        }
        return ret;
    }

In particular, the additional removal from the resourceList would trigger a call to equals, which in turn expects the XAResource to be available. But this is problematic if the resource was already closed.

Solution: we removed the resourceList since it was not really required.

Changes impacting client API

None.

Bug212902
Improve exception message on enlist / timeout

Severity:4
Affected version(s):6.0.x

Description

You can now see more descriptive state information to assess timeout possibility.

Technical details

Instead of suggesting a timeout, we now hint at timeout and show the actual transaction state in the exception. This allows developers to assess the right actionable steps to take.

For more info, see GitHub

Changes impacting client API

None.

]]> ExtremeTransactions 6.0.117 https://www.atomikos.com/Blog/ExtremeTransactions6dot0dot117 https://www.atomikos.com/Blog/ExtremeTransactions6dot0dot117?_t=1785915558 Guy Pardon 2026-08-05T09:39:18Z Release notes

Two timeout-correctness improvements for XA enlistment: an opt-in guard that refuses to enlist a resource on a transaction that has already timed out or been marked rollback-only — interrupting it before XA START instead of failing later at commit — and a fix so an already-timed-out coordinator no longer resets an enlisted resource's own timeout to the backend default (which held XA resources longer than needed). Plus, you can now skip the legacy Oracle AQ forceConnectionIntoXaMode workaround on spec-compliant JMS providers and on Oracle AQ 19c and later.

Bug227307
Atomikos JTA timeout not immediately interrupting ongoing transactions

Description

Atomikos now refuses to enlist a resource on a transaction that has already timed out or been marked rollback-only, interrupting a doomed transaction early rather than letting it proceed and fail later at commit. This behaviour is opt-in and off by default.

Technical details

Enable it by adding com.atomikos.icatch.feature.227307=true to your jta.properties (off by default in this release for backward compatibility). With the flag on, the refusal happens before XA START, so no XA branch is ever started: the doomed transaction rolls back through the normal path and the borrowed pooled connection or JMS session returns to the pool via the managed lifecycle (no leak). On the JDBC side the refusal surfaces to your code as an AtomikosSQLException (a normal SQLException); on the JMS side as a JMSException. The check is a cheap timeout/state test done before XA START — for a doomed transaction it actually saves the wasted round-trip to the backend. Because a flow that previously relied on the late (commit-time) failure will now fail fast at enlistment, we ship it off by default; enable it in a test environment first, then roll it out more broadly.

Changes impacting client API

None. The behaviour is opt-in via a feature flag and off by default.

Bug228434
Timed-out coordinator resets an enlisted resource's timeout to the backend default

Description

An already-timed-out coordinator no longer resets an enlisted resource's own transaction timeout to the backend default. This means a resource enlisted on an expired transaction is no longer held longer than necessary.

Technical details

When a transaction had already timed out (getTimeout() < 0=), XAResourceTransaction computed the remaining time and passed it to XAResource.setTransactionTimeout. Per the JTA/XA contract, setTransactionTimeout(0) means "reset to the default timeout", so the backend did not learn that the transaction had expired and reset its own timeout to the default — holding XA resources unnecessarily long. Atomikos now avoids passing a zero-or-negative value, so it no longer resets the resource timeout when the coordinator has already timed out. (Surfaced alongside the doomed-enlistment guard, also in this release.)

Changes impacting client API

None.

Feature226870
Skip the legacy Oracle AQ forceConnectionIntoXaMode workaround (opt-in feature flag)

Description

You can now skip the legacy Oracle AQ forceConnectionIntoXaMode workaround, avoiding wasteful per-session churn on spec-compliant JMS providers and on Oracle AQ 19c and later.

Technical details

The workaround opens a transacted JMS session and rolls it back before every createXASession() call, purely to coax older Oracle AQ into XA mode; for spec-compliant JMS providers (and Oracle AQ 19c+) this is unnecessary churn. Control it with com.atomikos.icatch.feature.226870 in jta.properties. The flag has inverted semantics: true keeps the legacy workaround (required for pre-19c Oracle AQ), false skips it. In this release the default is true (workaround preserved) for backward compatibility; set it to false if you run on Oracle AQ 19c+ or a spec-compliant JMS provider.

Changes impacting client API

None. Behaviour is controlled by an opt-in feature flag; the default preserves the previous behaviour.

SBOM — runtime dependencies are minimalistic

Concerning security and vulnerabilities: the following are the runtime dependencies (the SBOM) of our product. As you can see, the only transitive third-party dependencies are for the Spring Boot integration modules — because that is the only way to integrate with Spring Boot. All other modules / jars have no third-party runtime dependencies whatsoever.

This is compile + runtime scope; provided, test and non-propagating optional dependencies are excluded, so it is what your application actually receives. Look up the module(s) your application depends on.

To reproduce it yourself, run this in a project that depends on the Atomikos artifacts you use (use exactly this — not a bare dependency:tree, which would also list optional/provided libraries you are not given): 

mvn dependency:list -DincludeScope=runtime

Modules with no third-party runtime dependencies 

transactions
transactions-api
transactions-eclipselink
transactions-hibernate2
subscription
transactions-hibernate3
transactions-hibernate4
transactions-jdbc
transactions-jms
transactions-jndi-provider
transactions-jta
transactions-osgi
transactions-remoting
atomikos-util
transactions-allegrograph
transactions-hazelcast
transactions-jmx
transactions-jsp
transactions-logcloud
transactions-logutil
transactions-micrometer
transactions-monitoring
transactions-monitoring-logs
transactions-monitoring-stderr
transactions-opentracing
transactions-osgi-axt
transactions-remoting-recovery
transactions-spring
transactions-spring-boot-logcloud
transactions-tomcat

Per-module third-party runtime dependencies (opt-in, customer-chosen)

The dependencies below appear ONLY if you choose to use the corresponding integration module. They are the platform your application already runs — you added, say, the Spring Boot starter because you use Spring Boot. These are your own, customer-chosen dependencies: Atomikos does not inject anything into your infrastructure; you opt in by depending on the module. 

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

]]>