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 How Open Collaboration Made Atomikos Even More Flexible https://www.atomikos.com/Blog/HowOpenCollaborationMadeAtomikosEvenMoreFlexible https://www.atomikos.com/Blog/HowOpenCollaborationMadeAtomikosEvenMoreFlexible?_t=1779109637 Guy Pardon 2026-05-18T15:07:17Z Success stories Tech tips

In modern Java architectures, flexibility isn’t a luxury — it’s a requirement.

As teams move toward microservices, serverless deployments, and externalized infrastructure components, control over resources like database connections becomes just as important as transaction reliability itself.

This is where open collaboration across the ecosystem truly shines.

A Real-World Limitation Meets a Real-World Need

While working on integration scenarios, the team behind Open J Proxy — a relational database proxy designed for Java applications — ran into a practical limitation in Atomikos:

Connection pooling could not be disabled.

At first glance, this might not seem like a big deal. But in advanced architectures, it creates friction.

Open J Proxy, for example, manages connections centrally:
  • It uses your database drivers for proxy
  • Applications connect via virtual connections
  • The proxy controls the actual number of database connections
This approach enables:
  • Better resource efficiency (“less is more” with DB connections)
  • Elastic scaling for microservices and serverless workloads
  • Centralized control over connection limits
However, combining external pooling (proxy) with internal pooling (Atomikos) led to conflicts — a classic case of two layers trying to solve the same problem.

The Proposal: Make Pooling Optional

Instead of working around the limitation, the Open J Proxy team proposed a simple but powerful idea:

Allow connection pooling in Atomikos to be turned off — while keeping transaction management fully intact.

This would enable:
  • Seamless integration with external pooling solutions
  • Cleaner architecture boundaries
  • More control in modern cloud-native setups

From Suggestion to Shipping Feature

The Atomikos team reviewed the proposal — and acted on it.

The enhancement was implemented and released in Atomikos 6.0.1.

The result: connection pooling can now be disabled when needed

More details here:
https://www.atomikos.com/Blog/TransactionsEssentials6dot0dot1#Feature223216_Add_support_for_non_45pooled_40one_45off_41_connection_use

Why This Matters

This seemingly small change unlocks major benefits across the ecosystem:

1. Greater Flexibility

Developers can now decide where pooling belongs — inside Atomikos or elsewhere.

2. Better Integration

Works cleanly with:
  • Open J Proxy
  • Oracle UCP
  • Other external connection management systems

3. Cloud-Native Alignment

Modern architectures often favor:
  • Decoupled infrastructure layers
  • Centralized resource control
  • Stateless application instances
Atomikos now fits even more naturally into these environments.

4. No Compromise on Reliability

You still get what Atomikos is known for:
  • Exactly-once guarantees
  • XA-compliant distributed transactions
  • Reliable updates across databases and messaging systems
No retries. No duplicates. Just results.

A Broader Lesson for the Java Ecosystem

This is more than a feature update — it’s a case study in how open collaboration drives progress.
  • A real-world use case surfaced a limitation
  • A focused proposal addressed it
  • The maintainers responded thoughtfully
  • The entire ecosystem benefits
Small, targeted improvements like this often have outsized impact.

Final Thoughts

Atomikos continues to position itself as a lightweight, cloud-native transaction manager for Java microservices — one that adapts to modern architectures instead of constraining them.

And this update reinforces an important idea:

The best infrastructure tools evolve not just through design — but through collaboration.

]]> Microservice Transaction Patterns Book https://www.atomikos.com/Blog/MicroserviceTransactionPatternsBook https://www.atomikos.com/Blog/MicroserviceTransactionPatternsBook?_t=1778224545 Guy Pardon 2026-05-08T09:15:45Z Categories
MTP BCover small.jpg

Microservice Transaction Patterns Book

Get our FREE ebook and learn the following:

  • The problems with existing approaches towards microservice transactions
  • What can go wrong with your data consistency
  • Our simple patterns to fix things without extra coding

This book reveals essential things you should know to avoid crashing your next microservice project - so don't miss out!

Trusted By

320px-LVM Versicherungen logo svg.png BBP Interbank-Applications-Swift-Servicebureau .png gartner-logo.png nomura logo.png

]]> ExtremeTransactions 6.0.116 https://www.atomikos.com/Blog/ExtremeTransactions6dot0dot116 https://www.atomikos.com/Blog/ExtremeTransactions6dot0dot116?_t=1776427285 Guy Pardon 2026-04-17T14:01:25Z Release notes

Release notes for ExtremeTransactions 6.1.116

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.

Feature218192
Add logCloudDsName to Spring Boot properties

You can now set the logCloudDsName via Spring Boot.

Technical details

Quoting the customer's report:

Regarding the (JNDI) name of the LogCloud datasource bean used by Atomikos for datasource lookup, there is actually a property com.atomikos.icatch.logcloud_datasource_name. However, this cannot be set in Spring Boot applications via spring.jta.atomikos.properties..., because this property is missing in SpringJtaAtomikosProperties and AtomikosProperties.

Changes impacting client API

You can now set this in Spring Boot via the logcloudDatasourceName property.

Feature218193
Allow using Hikari for the logCloudDataSource

You can now use a Hikari datasource for logging the the LogCloud. Just point to it via the logcloud datasource name property.

About Severity

The severity levels we use are defined in our support terms and conditions.

Available to customers only. Want to become a customer?

Free Trial

]]> TransactionsEssentials 6.0.1 https://www.atomikos.com/Blog/TransactionsEssentials6dot0dot1 https://www.atomikos.com/Blog/TransactionsEssentials6dot0dot1?_t=1776427063 Guy Pardon 2026-04-17T13:57:43Z Categories

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.

BugINTERNAL
Cleanup pom for transactions-eclipselink

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.115 https://www.atomikos.com/Blog/ExtremeTransactions6dot0dot115 https://www.atomikos.com/Blog/ExtremeTransactions6dot0dot115?_t=1773391206 Guy Pardon 2026-03-13T09:40:06Z Release notes This release was superseded by ExtremeTransactions6dot0dot116

]]>