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.117 https://www.atomikos.com/Blog/ExtremeTransactions6dot0dot117 https://www.atomikos.com/Blog/ExtremeTransactions6dot0dot117?_t=1783348180 Guy Pardon 2026-07-06T16:29:40Z

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

]]> Ask AI to Build a Transaction Manager. Then Pull the Plug. https://www.atomikos.com/Blog/AskAIToBuildATransactionManagerThenPullThePlug https://www.atomikos.com/Blog/AskAIToBuildATransactionManagerThenPullThePlug?_t=1783063708 Guy Pardon 2026-07-03T09:28:28Z artificial-intelligence transactions AI can generate a transaction manager in minutes. But can it recover correctly when the coordinator crashes between prepare and commit? That's where the real engineering begins.

You can ask AI to build a transaction manager. It will happily do so. The code compiles. The demo works. Two databases commit together. The prepare phase happens. The commit phase happens. Everything looks correct.

Five minutes later you start wondering:

"Why did anyone ever pay for transaction management software?"

Then the server crashes. Now the real test begins.

The Happy Path Was Never the Product

Let's say you transfer money between two systems. One database debits Account A. Another database credits Account B. If everything works, then almost any transaction manager will get the job done. Including one generated by AI. That's not the interesting part. The interesting part is what happens when the crash comes at exactly the wrong moment. Suppose both databases have prepared their changes. The coordinator decides to commit. Then the machine dies. One database commits. The other never receives the commit instruction.

Now what? That question is the entire reason transaction managers exist. The happy path was never the product.

Recovery was.

Most Transaction Bugs Happen Months Later

The dangerous thing about transaction bugs is that they don't show up immediately. The demo passes. The tests pass. The code review passes. Everything looks fine. Then months later a server restarts during a deployment. Or a network connection drops. Or a database fails over.

Suddenly a transaction is left in doubt. One system thinks it committed. Another thinks it rolled back. You now have inconsistent data and no obvious explanation. Those are the failures that keep financial systems awake at night.

The Hard Part Isn't Commit. It's Recovery.

A real transaction manager has to answer questions that rarely appear in tutorials:
  • What happens if the coordinator crashes after prepare?
  • How does it recover pending transactions after restart?
  • How does it make sure recovery can run multiple times without causing duplicates?
  • What happens if a resource makes a unilateral decision?
  • What happens when drivers don't behave exactly according to the specification?
These problems are not theoretical.

Every production-grade transaction manager contains years of lessons learned from solving them. The code often looks more complicated than necessary. Usually that's because someone already learned the hard way why it wasn't.

Why Open Source Doesn't Change This

Our transaction coordinator is open source. You can inspect every line. We want people to do exactly that. But reading the code is not the difficult part. Understanding why certain pieces exist is. Many of the seemingly strange checks, recovery paths, and corner-case handlers are there because of real incidents in real production systems. To a fresh reader, some of them look redundant. To someone who has lived through a failed recovery at 2 a.m., they look essential.

The Real Value

AI has made writing code cheaper than ever. That's a remarkable achievement. But transaction management was never about writing code. It was always about guaranteeing an outcome.

The value is not in coordinating successful transactions. The value is in recovering unsuccessful ones. So by all means, ask AI to build a transaction manager.

Then ask it what happens when the coordinator crashes between prepare and commit. The distance between those two answers is where the real engineering begins.

Tags: artificial-intelligence, transactions

]]> TransactionsEssentials 6.0.1 https://www.atomikos.com/Blog/TransactionsEssentials6dot0dot1 https://www.atomikos.com/Blog/TransactionsEssentials6dot0dot1?_t=1783062656 Guy Pardon 2026-07-03T09:10:56Z Categories

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 4.0.46 https://www.atomikos.com/Blog/ExtremeTransactions4dot0dot46 https://www.atomikos.com/Blog/ExtremeTransactions4dot0dot46?_t=1779778823 Guy Pardon 2026-05-26T09:00:23Z ExtremeTransactions A small but important improvement of new recovery...

156968: Refresh XAResource handle when errors during recovery scan

We've improved a prior fix in the 4.0.x recovery mechanism so we can avoid that stale connections stay around during recovery.

Available to customers only. Want to become a customer?

Send me a quote

]]> ExtremeTransactions 4.0.44 https://www.atomikos.com/Blog/ExtremeTransactions4dot0dot44 https://www.atomikos.com/Blog/ExtremeTransactions4dot0dot44?_t=1779778821 Guy Pardon 2026-05-26T09:00:21Z ExtremeTransactions JDBC and TCC/REST improvements

154438: Support for JDBC4 isValid connection testing

We've implemented support for JDBC4 isValid connection tests by the driver. To enable, set useDriverBasedConnectionValidation to true on the AtomikosDataSourceBean.

155622: TCC / REST: refine options error handling to tolerate 405 (not implemented)

We now tolerate participant service without OPTIONS method so confirmation can still proceed.

Available to customers only. Want to become a customer?

Send me a quote

]]>