Feature208965

Improve fairness even more while growing the connection pool

Releases 6.0.110 and 6.0.111 offered a fairer way of growing the connection pool. This has been optimised further.

Technical details

The two prior releases attempted to offer a fairer way of growing the connection pool, so a thread that requests an extra connection could also use it. However, there the algorithm was still not as good as it could be, because it did the following:

1. Thread A requests growing the pool
2. The pool adds an extra connection
3. The extra connection is put into the pool of available connections
4. Thread A then quickly fetches the new connection

While this performed better than before, this still allowed for another thread to hijack the connection between steps 3 and 4.

We now changed this to the following:

1. Thread A requests growing the pool
2. The pool adds an extra connection
3. The pool marks the connection as being used
4. The extra connection is put into the pool of available connections
5. The extra connection is returned for Thread A to use

The extra step 3 implies that no other thread can take the connection after step 4. Thus, Thread A is always able to use the new connection.

Changes impacting client API

None.

Issue202334

Modify Tomcat examples to use Docker

Severity:	4
Affected version(s):	6.0.110

Description

The Tomcat examples have been modified to user Docker, but this does not work on all platforms yet.

Technical details

The Docker image generated to run the Tomcat examples contains a Java JDK that is not binary compatible with all platforms yet.

Bug208965

Fix race condition in new pool growth algorithm

Severity:	2
Affected version(s):	6.0.110

Description

The improvement shipped as part of release 6.0.110 contained a bug that cause race conditions on concurrent pool usage. This is no longer the case;

Technical details

The improvement that made growing the pool fairer for concurrent waiting threads contained a bug that led to attempts to use the same connection in two different threads, leading to exceptions like this one:

com.atomikos.datasource.ResourceException: XA resource '5684df3b-2192-4bd1-ba12-91cb2d55edac': resume for XID 'xid://61653731323262342D336561322D343761362D613461632D373861393064643062616539:31302E3130312E31332E392E746D31343035303633' raised -6: the XA resource did not expect this command in the current context
   at com.atomikos.datasource.xa.XAResourceTransaction.resume(XAResourceTransaction.java:240)
   at com.atomikos.datasource.xa.session.BranchEnlistedStateHandler.<init>(BranchEnlistedStateHandler.java:42)
   at com.atomikos.datasource.xa.session.NotInBranchStateHandler.checkEnlistBeforeUse(NotInBranchStateHandler.java:46)
   at com.atomikos.datasource.xa.session.TransactionContext.checkEnlistBeforeUse(TransactionContext.java:58)
   at com.atomikos.datasource.xa.session.SessionHandleState.notifyBeforeUse(SessionHandleState.java:185)
   at com.atomikos.jdbc.internal.AtomikosJdbcConnectionProxy.enlist(AtomikosJdbcConnectionProxy.java:89)
   at com.atomikos.jdbc.internal.AtomikosJdbcConnectionProxy.updateTransactionContext(AtomikosJdbcConnectionProxy.java:62)
   at com.atomikos.jdbc.internal.AbstractJdbcConnectionProxy.prepareStatement(AbstractJdbcConnectionProxy.java:65)
   at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
   at java.base/java.lang.reflect.Method.invoke(Method.java:580)
   at com.atomikos.util.DynamicProxySupport.callProxiedMethod(DynamicProxySupport.java:167)
   at com.atomikos.util.DynamicProxySupport.invoke(DynamicProxySupport.java:121)
   at jdk.proxy3/jdk.proxy3.$Proxy235.prepareStatement(Unknown Source)
   at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
   at java.base/java.lang.reflect.Method.invoke(Method.java:580)
   at org.springframework.jdbc.datasource.TransactionAwareDataSourceProxy$TransactionAwareInvocationHandler.invoke(TransactionAwareDataSourceProxy.java:262)
   at jdk.proxy3/jdk.proxy3.$Proxy232.prepareStatement(Unknown Source)
   at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.java:153)
   at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:183)
   at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:155)
   at org.hibernate.sql.exec.spi.JdbcSelectExecutor.lambda$list$0(JdbcSelectExecutor.java:85)
   at org.hibernate.sql.results.jdbc.internal.DeferredResultSetAccess.executeQuery(DeferredResultSetAccess.java:231)
   at org.hibernate.sql.results.jdbc.internal.DeferredResultSetAccess.getResultSet(DeferredResultSetAccess.java:167)
   at org.hibernate.sql.results.jdbc.internal.JdbcValuesResultSetImpl.advanceNext(JdbcValuesResultSetImpl.java:218)
   at org.hibernate.sql.results.jdbc.internal.JdbcValuesResultSetImpl.processNext(JdbcValuesResultSetImpl.java:98)
   at org.hibernate.sql.results.jdbc.internal.AbstractJdbcValues.next(AbstractJdbcValues.java:19)
   at org.hibernate.sql.results.internal.RowProcessingStateStandardImpl.next(RowProcessingStateStandardImpl.java:66)
   at org.hibernate.sql.results.spi.ListResultsConsumer.consume(ListResultsConsumer.java:202)
   at org.hibernate.sql.results.spi.ListResultsConsumer.consume(ListResultsConsumer.java:33)
   at org.hibernate.sql.exec.internal.JdbcSelectExecutorStandardImpl.doExecuteQuery(JdbcSelectExecutorStandardImpl.java:209)
   at org.hibernate.sql.exec.internal.JdbcSelectExecutorStandardImpl.executeQuery(JdbcSelectExecutorStandardImpl.java:83)
   at org.hibernate.sql.exec.spi.JdbcSelectExecutor.list(JdbcSelectExecutor.java:76)
   at org.hibernate.sql.exec.spi.JdbcSelectExecutor.list(JdbcSelectExecutor.java:65)
   at org.hibernate.query.sqm.internal.ConcreteSqmSelectQueryPlan.lambda$new$2(ConcreteSqmSelectQueryPlan.java:137)
   at org.hibernate.query.sqm.internal.ConcreteSqmSelectQueryPlan.withCacheableSqmInterpretation(ConcreteSqmSelectQueryPlan.java:381)
   at org.hibernate.query.sqm.internal.ConcreteSqmSelectQueryPlan.performList(ConcreteSqmSelectQueryPlan.java:303)
   at org.hibernate.query.sqm.internal.QuerySqmImpl.doList(QuerySqmImpl.java:509)
   at org.hibernate.query.spi.AbstractSelectionQuery.list(AbstractSelectionQuery.java:427)
   at org.hibernate.query.Query.getResultList(Query.java:120)
   at org.springframework.data.jpa.repository.query.JpaQueryExecution$ExistsExecution.doExecute(JpaQueryExecution.java:315)
   at org.springframework.data.jpa.repository.query.JpaQueryExecution.execute(JpaQueryExecution.java:92)
   at org.springframework.data.jpa.repository.query.AbstractJpaQuery.doExecute(AbstractJpaQuery.java:149)
   at org.springframework.data.jpa.repository.query.AbstractJpaQuery.execute(AbstractJpaQuery.java:137)
   at org.springframework.data.repository.core.support.RepositoryMethodInvoker.doInvoke(RepositoryMethodInvoker.java:170)
   at org.springframework.data.repository.core.support.RepositoryMethodInvoker.invoke(RepositoryMethodInvoker.java:158)
   at org.springframework.data.repository.core.support.QueryExecutorMethodInterceptor.doInvoke(QueryExecutorMethodInterceptor.java:169)
   at org.springframework.data.repository.core.support.QueryExecutorMethodInterceptor.invoke(QueryExecutorMethodInterceptor.java:148)
   at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184)
   at org.springframework.data.projection.DefaultMethodInvokingMethodInterceptor.invoke(DefaultMethodInvokingMethodInterceptor.java:70)
   at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184)
   at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:379)
   at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:119)
   at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184)
   at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:138)
   at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184)
   at org.springframework.data.jpa.repository.support.CrudMethodMetadataPostProcessor$CrudMethodMetadataPopulatingMethodInterceptor.invoke(CrudMethodMetadataPostProcessor.java:135)
   at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184)
   at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:97)
   at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184)
   at datadog.trace.instrumentation.springdata.RepositoryInterceptor.invoke(RepositoryInterceptor.java:43)
   at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184)
   at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:223)
   at jdk.proxy3/jdk.proxy3.$Proxy395.existsByRetailTaxpayerIdIn(Unknown Source)
   at .portfolio_management.taxpayer.PendingSyncService.hasTaxpayerPendingSync(PendingSyncService.java:89)
   at .portfolio_management.executionaware.evaluation.EvaluationJob$Runner.washGroupCanBeEvaluated(EvaluationJob.java:145)
   at xxx.portfolio_management.executionaware.evaluation.EvaluationJob$Runner.shouldRunJob(EvaluationJob.java:137)
   at xxx.portfolio_management.executionaware.evaluation.EvaluationJob$Runner.run_aroundBody0(EvaluationJob.java:113)
   at xxx.portfolio_management.executionaware.evaluation.EvaluationJob$Runner$AjcClosure1.run(EvaluationJob.java:1)
   at org.springframework.transaction.aspectj.AbstractTransactionAspect.ajc$around$org_springframework_transaction_aspectj_AbstractTransactionAspect$1$2a73e96cproceed(AbstractTransactionAspect.aj:67)
   at org.springframework.transaction.aspectj.AbstractTransactionAspect$AbstractTransactionAspect$1.proceedWithInvocation(AbstractTransactionAspect.aj:73)
   at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:379)
   at org.springframework.transaction.aspectj.AbstractTransactionAspect.ajc$around$org_springframework_transaction_aspectj_AbstractTransactionAspect$1$2a73e96c(AbstractTransactionAspect.aj:71)
   at xxx.portfolio_management.executionaware.evaluation.EvaluationJob$Runner.run(EvaluationJob.java:112)
   at xxx.portfolio_management.executionaware.evaluation.EvaluationJob$Runner.run(EvaluationJob.java:61)
   at xxx.dj.DelayedJobWorker.lambda$process$0(DelayedJobWorker.java:90)
   at xxx.telemetry.metrics.Metric.lambda$delayedJobTimer$0(Metric.java:25)
   at io.micrometer.core.instrument.AbstractTimer.record(AbstractTimer.java:187)
   at xxx.telemetry.metrics.Metric.lambda$delayedJobTimer$1(Metric.java:33)
   at io.micrometer.core.instrument.AbstractTimer.record(AbstractTimer.java:187)
   at xxx.telemetry.metrics.Metric.delayedJobTimer(Metric.java:33)
   at xxx.telemetry.metrics.Metric.delayedJobTimer(Metric.java:29)
   at xxx.dj.DelayedJobWorker.lambda$process$5(DelayedJobWorker.java:86)
   at xxx.telemetry.metrics.Metric.lambda$delayedJobTimer$0(Metric.java:25)
   at io.micrometer.core.instrument.AbstractTimer.record(AbstractTimer.java:187)
   at xxx.telemetry.metrics.Metric.lambda$delayedJobTimer$1(Metric.java:33)
   at io.micrometer.core.instrument.AbstractTimer.record(AbstractTimer.java:187)
   at xxx.telemetry.metrics.Metric.delayedJobTimer(Metric.java:33)
   at xxx.telemetry.metrics.Metric.delayedJobTimer(Metric.java:29)
   at xxx.dj.DelayedJobWorker.process(DelayedJobWorker.java:51)
   at xxx.dj.DelayedJobProcessor.lambda$claimAndSubmitJobs$0(DelayedJobProcessor.java:148)
   at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
   at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
   at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
   at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: org.postgresql.xa.PGXAException: Connection is busy with another transaction
   at org.postgresql.xa.PGXAConnection.start(PGXAConnection.java:199)
   at com.atomikos.datasource.xa.XAResourceTransaction.resume(XAResourceTransaction.java:234)
   ... 94 more

Changes impacting client API

None.

Issue202334

Modify Tomcat examples to use Docker

Severity:	4
Affected version(s):	6.0.110

Description

The Tomcat examples have been modified to user Docker, but this does not work on all platforms yet.

Technical details

The Docker image generated to run the Tomcat examples contains a Java JDK that is not binary compatible with all platforms yet.

Feature207056

Improved core classes for concurrency / threading

You can now benefit from reduced synchronisation overhead thanks to concurrent maps usage in our core classes.

Technical details

We've added 2 new implementation classes: DefaultTransactionService and DefaultCompositeTransactionManager. These comply with our newly documented Concurrency Model for correctness in multi-threaded applications. We now also use concurrent maps thanks to this this contribution on github.

The new DefaultTransactionService also has better / simpler shutdown logic for the transaction service.

Changes impacting client API

This feature can (for now) be toggled with a flag in jta.properties:

   om.atomikos.icatch.feature.207056 = true 

This is enabled by default because we are confident it works better than before. If you experience problems after upgrading, set this to false…

Feature203242

Retry file lock on startup

You can now shift Kubernetes pods by starting a new pod while the old one is still terminating.

Technical details

In Kubernetes environments pods might be terminated and shifted to other nodes. Because of this the configured log path might be in use if the old pod is about to terminate and the new one is starting up. To be able to use the same LogFileLock we now offer retry attempts for the new pod which is trying to acquire the lock.

Changes impacting client API

None, we have reasonable default configuration properties in JTA Properties, prefixed with com.atomikos.icatch.log_lock_acquisition.

Feature201646

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

You can now use the same JTA and JMS dependency versions of Spring Boot's rather than the ones we specify.

Technical details

For Spring Boot 2 we used to specify a particular version for each of JTA and JMS. This would override the versions that Spring Boot prefers. We no longer do this.

Changes impacting client API

None.

Feature207758

Examples for Hibernate 7

You can now check the examples for Hibernate 7.

Technical details

We've added working samples for Hibernate 7.

Bug202474

Refine exception message when creating a JDBC statement fails

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

Description

You can now expect more accurate exception messages when creating a JDBC statement fails

Technical details

We used to have one generic exception message when a statement could not be created, each time suggesting a timeout of the transaction. This was confusing if the real reason was, for instance, the transaction having been marked for rollback only.

The code has been refined live this:

   TxState state = ct.getState();
   if (state == TxState.ACTIVE) {
      ct.registerSynchronization(new JdbcRequeueSynchronization(this, ct));
   } else if (state == TxState.MARKED_ABORT){
      AtomikosSQLException.throwAtomikosSQLException("The transaction has been set to rollback-only");
   } else {
      AtomikosSQLException.throwAtomikosSQLException("The transaction has timed out - try increasing the timeout if needed");
   }

Changes impacting client API

None.

Bug202466

Interposed synchronisation instances not called on regular rollback

Severity:	3
Affected version(s):	6.O.x

Description

Interposed synchronisation instances are now called on regular rollback also.

Technical details

See this github issue for details.

Changes impacting client API

None.

Bug208965

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

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

Description

Getting a new connection is now more efficient.

Technical details

Details are explained in this github issue.

Changes impacting client API

None.

Bug209260

Expose AtomikosSQLException in public package (for OSGi)

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

Description

The class AtomikosSQLException was not exposed as public in OSGi.

Technical details

The class AtomikosSQLException was not exposed as public in OSGi because it was in an "internal" package. This class has been moved to a public package instead, so it can be used with OSGi.

Changes impacting client API

You have to change the imports when your code references this exception.

Bug207055

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

Severity:	3
Affected version(s):	5.0.x, 6.0.x and prior (decorated) releases

Description

Timeout / rollback of a subtransaction no longer appears as a commit to the parent transaction.

Technical details

Timeout with subsequent rollback of a subtransaction would interfere with a later commit of the parent transaction: the state handler for the subtransaction would erroneously reply with READONLY upon 2PC prepare. This would make it seem to the parent transaction as though commit may proceed. We've fixed this by checking for timeout upon prepare of a subtransaction. Most people are not using subtransaction functionality, but those who do will benefit from this fix.

Changes impacting client API

None.

Bug207046

Improve 2-phase commit for imported transaction to align with the new concurrency model

Severity:	3
Affected version(s):	5.0.x, 6.0.x and prior (decorated) releases

Description

We improved the way imported transactions are handled in the case of network timeouts - so it aligns with our concurrency model.

Technical details

This release includes an improved concurrency implementation (as per feature 207056 above), along with a newly documented concurrency model as shown in Concurrency Model. We've updated the handling of imported transactions to be consistent with the new concurrency model. In particular, the following scenario has been improved:

• A remote client propagates a transaction to your service, possibly on a number of times on different invocations.
• The last invocation "I" appears to "fail" at the remote client due to a network timeout, but the invocation as actually still active at your service.
• The remote client decides to terminate the transaction by either commit (which is possible if "I" is considered optional) or rollback.
• Depending on the complexity of the remote transaction, this will lead to either of an incoming "PC": prepare, rollback or 1-phase commit call in your service.
• The classical way we dealt with this was instant rollback triggered by the incoming "2PC", but this violates our new concurrency model.
• So we now let the pending active invocation do the rollback instead - in line with the concurrency model.

Changes impacting client API

None.

Bug207146

High memory consumption due to adding JDBC statements multiple times to the same list

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

Description

Creating many JDBC statements no longer leads to high memory consumption.

Technical details

For technical reasons we keep a "cached" collection of JDBC statements. Due to a bug, such statements were added multiple times to a list. We fixed this by:

• Changing the list to a Set, and
• Removing the lines of code that added statements more than once.

Changes impacting client API

None.

Bug209259

Improve thread-safety of CheckedExportingTransactionManager

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

Description

We improved the tread-safety of CheckedExportingTransactionManager in module transactions-remoting.

Technical details

We changed the use of a HashMap to a ConcurrentHashMap for pending request synchronisation instances.

Changes impacting client API

None.

Bug202750

ConnectionPool: endless loop on interrupt during waitForConnection

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

Description

Interruptions during Spring Boot shutdown are now handled better by the connection pool.

Technical details

Full details as disclosed in the original report:

We experienced a somewhat strange behaviour with Atomikos in a situation, where our application (Spring Boot) is shutting down while some threads are waiting for a connection. In this shutdown-situation, Spring Boot sends an 'interupt' to all running threads. The Atomikos ConnectionPool method 'waitForAtLeastOneAvailableConnection()' handles this InterruptedException by invoking the InteruptedExceptionHelper. This in turn logs the exception and re-interrupts the thread. This is the correct pattern to interrupt possible further waits in the call stack.

But the method does not leave the while-loop. This causes a loop for the remaining borrowConnectionTimeout, leading to a very large amount of exception logs.

Changes impacting client API

None.

Bug210111

Missing jar in eval download: transactions-tomcat-jakarta

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

Description

You can now use the Tomcat Jakarta functionality in the free trial download.

Technical details

The relevant jar file for this was missing from the evaluation zip file. It has now been added.

Issue202334

Modify Tomcat examples to use Docker

Severity:	4
Affected version(s):	6.0.110

Description

The Tomcat examples have been modified to user Docker, but this does not work on all platforms yet.

Technical details

The Docker image generated to run the Tomcat examples contains a Java JDK that is not binary compatible with all platforms yet.

Added support for Jakarta EE, Spring Boot 3 and Hibernate 6.

Upgrading from 5.0 to 6.0

This release was very hard to do. Not because we wanted many new features included (there are not that many, actually), but rather because it was a balancing act between stability / backwards compatibility and new "breaking change" emerging platforms (specifically: Spring Boot 3, Hibernate 6 and their dependencies on JakartaEE and very recent Java versions).

We think we did a good job: just like the previous release 5.0, this new release can run on "good old" Java 8 for most modules, except for Spring Boot 3 integration (which requires Java 17 as per Spring Boot) and Hibernate 6. So if your application worked with release 5.0 then it should still work, provided that you do the following:

Add extra dependencies explicitly to your POM

We now support both javax and jakarta namespaces for the Java enterprise APIs, by offering regular jars as well as "jakarta" jars (with the corresponding classifier in the jar names). These jakarta jars are generated at build time with the Eclipse transformer utility.

In order to do this, we had to break the transitive dependency mechanism (which, incidentally, also avoids pulling in vulnerable 3rd party code libs). So: except for Spring Boot 3 apps, this means that you will now have to add the following dependency to your pom file (or you risk facing ClassNotFoundExceptions):

The traditional javax style

    <dependency>
         <groupId>com.atomikos</groupId>
         <artifactId>transactions-jta</artifactId>
         <version>6.0.109</version> <!-- Commercial, for open source use version 6.0.0 -->
    </dependency>

     <dependency>
         <groupId>jakarta.jms</groupId>
         <artifactId>jakarta.jms-api</artifactId> 
         <!-- NOTE: despite "jakarta" in the name, this version is still a javax jar -->
         <version>2.0.3</version>
     </dependency>

     <dependency>
         <groupId>javax.transaction</groupId>
         <artifactId>jta</artifactId>
         <version>1.1</version>
      </dependency>

The new jakarta style

      <dependency>
         <groupId>com.atomikos</groupId>
         <artifactId>transactions-jta</artifactId>
         <version>6.0.109</version> <!-- Commercial, for open source use version 6.0.0 -->
         <classifier>jakarta</classifier>
      </dependency>

      <dependency>
         <groupId>jakarta.jms</groupId>
         <artifactId>jakarta.jms-api</artifactId>
         <version>3.1.0</version>
      </dependency>

      <dependency>
         <groupId>jakarta.transaction</groupId>
         <artifactId>jakarta.transaction-api</artifactId>
         <version>2.0.1</version>
      </dependency>

Override the new JMS behaviour to revert to prior release behaviour

We now support JMS 2. This required some changes to the JMS session creation behaviour, so if you rely on the "old" JMS behaviour then set the following property on the AtomikosConnectionFactoryBean:

     AtomikosConnectionFactoryBean cf = new AtomikosConnectionFactoryBean();
     // 1 sets behaviour like in releases 3.9-5.0, 0 sets behaviour like in releases pre-3.9
     cf.setSessionCreationMode(1); 

For more details, see the javadoc of the AtomikosConnectionFactoryBean class.

Drop any reapTimeout property

We've removed reap functionality from the pool, so remove any reapTimeout property in your datasource or connection factory config.

Detailed release notes

If you like the nitty gritty details, then the following sections are for you!

Feature199869

Spring Boot 3 Starter

We added a starter for Spring Boot 3.

Technical details

Spring Boot 3 has made a "big bang" upgrade to Jakarta EE and Java 17, with all complications involved. You can now use Atomikos with Spring Boot 3 by means of our new Spring Boot 3 starter module.

Changes impacting client API

Spring Boot 3 requires Java 17 or higher, plus all JakartaEE libraries (and for course Atomikos releases 6.0 or higher). Note that this means you will also need JakartaEE JMS drivers, and JakartaEE persistence providers. Hurray.

You need the following dependency to use Spring Boot 3:

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

For the JakartaEE JMS and JTA APIs: we've added those to the Spring Boot 3 starter module already - so you don't have to bother.

Feature197500

Support JakartaEE libraries and packages

Description

We now also support JakartaEE (in addition to the "old" JEE with javax namespaces).

Technical details

All relevant modules are now available in both a traditional variant and a JakartaEE variant, the latter generated with the Eclipse transformer utility during the build. JakartaEE jars carry the same name as their traditional counterparts, but have the additional classifier "jakarta" in the jar file name to distinguish them.

The choice for this strategy was heavily driven by our desire to still support Java 8 applications that can't upgrade to Java 17 or JakartaEE right now.

The previous statement probably deserves some explanation: after some initial attempts it was painfully clear to us that upgrading from Java 8 to Java 17 is nothing short of a nightmare.

[Oh and by the way, we figure that this is the reason why extended support for Java 8 is available until 2030, the longest of all Java versions at the time of publication. Yes, that means Java 8 should be supported for longer than Java 17 - go figure that!]

Our chosen approach should allow existing installations to upgrade to our 6.0 release without the need to upgrade to JakartaEE and/or Java 17 at the same time.

Past experience with our customers has shown that even a "simple" upgrade from Java 6 to Java 8 can be a huge roadblock - especially if the development team is gone and only operations teams are left. So we prefer to keep upgrading a seamless and straightforward process, without requiring needless Java updates at the same time. We are sure that you will appreciate that.

The "downside" of this choice is that you can no longer count on transitive dependencies as much as you did, because many modules now have 2 variants available (and hence the transitive dependencies would not necessarily match the right variant). While this may seem a disadvantage, it actually increases security because there are no longer transitive dependencies on 3rd party jars either (so you avoid pulling in vulnerabilities).

So: you have to add some dependencies manually that were transitive before. But the effort required is significantly lower than the effort it would take to upgrade your code base towards Java 17 and JakartaEE all at once.

Changes impacting client API

As explained in the upgrade section above: you need to declare some extra dependencies. Also, you have to be careful to use the right combination of Jakarta-enabled jars in your application. To this end, we have defined BOM files that list all the jars designed to work together:

• transactions-essentials versus transactions-essentials-jakarta
• extreme-transactions versus extreme-transactions-jakarta

You can check these BOMs for inspiration on which jars to use / combine in your application. If you are curious where to find them: check groupId=com.atomikos and artifactId=name_of_BOM_file.

Feature199608

Hibernate 6 support

Description

You can now easily use Hibernate 6 in combination with our product!

Technical details

Hibernate 6 is also in the JakartaEE camp, so of course you need JakartaEE support to be able to use it. Well, as we've explained above: we have done just that.

To use Hibernate 6, it suffices to use transactions-hibernate4 in the jakarta flavour.

For a working sample: check the supplied examples project called examples-hibernate6 or see the summary POM snippet below.

Changes impacting client API

No real changes are needed, but you do have to add the correct POM dependencies:

      <dependency>
         <groupId>com.atomikos</groupId>
         <artifactId>transactions-hibernate4</artifactId>
         <version>6.0.109</version>
         <classifier>jakarta</classifier>
      </dependency>
      <dependency>
         <groupId>com.atomikos</groupId>
         <artifactId>transactions-jdbc</artifactId>
         <version>6.0.109</version>                                              
         <classifier>jakarta</classifier>
      </dependency>
      <dependency>
         <groupId>com.atomikos</groupId>
         <artifactId>transactions-jta</artifactId>
         <version>6.0.109</version>
         <classifier>jakarta</classifier>
      </dependency>
      <dependency>
         <groupId>jakarta.transaction</groupId>
         <artifactId>jakarta.transaction-api</artifactId>
         <version>2.0.1</version>
      </dependency>
      <dependency>
         <groupId>jakarta.persistence</groupId>
         <artifactId>jakarta.persistence-api</artifactId>
         <version>3.1.0</version>
      </dependency>

Of course, you also need the Hibernate 6 dependencies themselves - but we'll leave that up to you…

Feature85601

JMS 2.0 support

Description

We now have (minimal) support for JMS 2.0.

Technical details

As required by JakartaEE and Spring Boot 3, we needed some support for JMS 2.0. For the sake of releasing on time, this support is only partial: we do not yet support the new JMSContext API. Spring Boot 3 does not seem to need it, so that should be fine for now. Attempting to call any of the createContext methods on the AtomikosConnectionFactoryBean will throw UnsupportedOperationException.

Changes impacting client API

Session creation behaviour has changed due to the clarification of session creation behaviour in JMS 2.0 (which is incompatible with what we had in prior releases). As you can see in the table below, the differences are in the combined interpretation of:

• a JTA transaction being present on the calling thread or not,
• the value set for localTransactionMode and
• the value of the sessionTransacted flag when creating a session.

Prior to JMS 2.0, session creation had some fuzzy border cases where the interpretation was left to the party implementing the specs (like Atomikos). In JMS 2.0 this has been addressed. Needless to say, the probably of a perfect match with our interpretation was next to zero - so we had to make some changes.

To preserve compatibility your instances of AtomikosConnectionFactoryBean now offer an extra method setSessionCreationMode(int mode) which changes behaviour as described below. The default is value 2 (JMS 2.0) so for compatibility with 5.0, try value 1. For compatibility with pre-3.9 installations, try value 0.

SessionCreationMode.JMS_2_0 (the default as of release 6.0), resolving to constant value 2

existing JTA transaction for thread	localTransactionMode	resulting session
true	ignored	XA session
false	false	XA session
false	true	non-XA session according to sessionTransacted/acknowledgeMode parameters

SessionCreationMode.PRE_6_0 (optional, for backward compatibility) - resolving to constant value 1

localTransactionMode	sessionTransactedFlag	resulting session
false	ignored	XA session
true	ignored	non-XA session according to sessionTransacted/acknowledgeMode parameters

SessionCreationMode.PRE_3_9 (optional, for backward compatibility and equivalent to ignoreSessionTransactedFlag = false) - resolving to constant value 0

localTransactionMode	sessionTransactedFlag	resulting session
false	true	XA session
other	other	non-XA session according to sessionTransacted/acknowledgeMode parameters

You can also find this in the javadoc of the AtomikosConnectionFactoryBean.

Feature20711

Support for TransactionSynchronizationRegistry

Description

We now offer an implementation of TransactionSynchronizationRegistry defined in the more recent JTA specifications.

Technical details

You can use an instance of com.atomikos.icatch.jta.TransactionSynchronizationRegistryImp contained in module transactions-jta.jar.

Unless you are a vendor of persistence providers, you probably won't ever need this class so we'll keep the explanation to a minimum - since vendors of persistence providers already know all there is to know.

Changes impacting client API

An extra class available in our distribution, for you to use if you want to.

Feature199530

Make the transaction template thread-safe

Description

Instances of com.atomikos.icatch.jta.template.TransactionTemplate are now tread-safe.

Technical details

The first implementations of our template were not intended for threaded use cases. Based on customer feedback, we have changed that - so you can now reuse the same instance in different threads - just like Spring's template.

Changes impacting client API

Instead of having to create multiple template instances, you can now reuse the same instance in different places of your code base. This should simplify your configuration and code base.

Feature192016

Better support for borrowConnection timeouts in the pool

Description

We've improved the pool logic so that borrow requests can better respect the timeout.

Technical details

When a connection is requested and none is available, new connections would be created in the application's thread. In case of network issues, this would block the application's thread, possibly for much longer than the borrowConnectionTimeout setting would (and should) allow. That's because there is no easy way to interrupt a blocked IO request.

We now improved this as follows:

• There is a separate background thread that grows the pool when needed.
• The application's thread waits for this thread to grow the pool, but no longer than specified by borrowConnectionTimeout.

Changes impacting client API

No real changes are needed, except that it should work better.

Feature189885

Refactor shutdown: improve waiting for in-flight transactions

Description

We have simplified and improved the shutdown logic.

Technical details

Shutdown used to wait for a timeout bound by the value of com.atomikos.icatch.default_max_wait_time_on_shutdown. Recovery itself is already bound by a different parameter: com.atomikos.icatch.default_max_timeout. The previous logic used to mix those two and the results were not always clear.

We have simplified this to the following:

• Shutdown waits for all active transactions to finish in the JVM.
• Then it performs a recovery pass to clean up as much as possible.
• If both previous steps worked fine then there are no pending transactions and the transaction log files can be deleted.
• On the other hand, if either step has issues then the transaction log files have to be kept (we log a warning for that).

Changes impacting client API

You no longer need com.atomikos.icatch.default_max_wait_time_on_shutdown in your jta.properties file. Beware that shutdown duration is bound by the value of com.atomikos.icatch.default_max_timeout - unless you use the "forceShutdown" option.

Feature182107

Remove user / password properties from MessageDrivenContainer

Description

The user and password properties have been removed from com.atomikos.jms.extra.MessageDrivenContainer because they were never used anyway.

Technical details

Instances of this class delegate to com.atomikos.jms.AtomikosConnectionFactoryBean to create connections. The latter is also configured with a user and password, and those are the values that are actually being used.

As a result, keeping two unused properties in the com.atomikos.jms.extra.MessageDrivenContainer class was confusing - so we have removed those.

Changes impacting client API

You need to remove any references to these properties from your configuration.

Feature199528

Drop reaping functionality from the pools

Description

We've removed the reaping functionality from the pools.

Technical details

Reaping was when our pools would take away connections that were being held onto for too long.

Historically, reaping functionality has caused more problems / confusion than it solved. Moreover, it was intended to fix application-level connection leaks, meaning bugs in the application (as opposed to bugs in our code base). We felt that became a source of needless complexity.

We believe that the correct way of fixing application-level connection leaks is by fixing the application, rather than abruptly reaping connections away from that application. So our 6.0 release seemed a good time to remove that feature.

Changes impacting client API

Remove any references to reapTimeout from your configuration.

Bug197505

Avoid that defaults in the Spring Boot starter override jta.properties

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

Description

You can now count on the property values from jta.properties to be taken into account even with Spring Boot.

Technical details

The Atomikos JTA properties implementation in our Spring Boot starter would define default values for many properties, meaning that their value specified jta.properties would not be taken into account. This has now been fixed.

Changes impacting client API

Your properties specified in jta.properties should now work.

Bug197362

Clarify message if rest port not set in client

Severity:	1/2/3/4
Affected version(s):	5.0.x

Description

You can now count on a better error message when the AtomikosRestPort URL is not set (for transactions across remoting calls).

Technical details

When the AtomikosRestPort URL was not set, the client template would report a misleading message saying that there is no transaction for the thread. Instead, the root cause is a URL that is missing - so we fixed that for you.

Changes impacting client API

None.

Bug197506

Support diamond case architectures for readOnly remoting

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

Description

You can now use transitive readOnly remoting transactions in all cases.

Technical details

As outlined in this GitHub issue there was a problem with readOnly invocations when:

• the same shared service was called over different paths, and
• all invocations were readOnly

This is known as a "diamond case" because the invocation diagram looks like a diamond.

This issue has been fixed in the following way: our product will now avoid the readOnly optimisation in this specific scenario. This is still correct, at a minor performance overhead in the exotic cases where this does happen.

Changes impacting client API

None.

Bug200555

Also close Callable- and PreparedStatements when JDBC connection is closed

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

Description

Now you can close a JDBC connection and also have the Callable- and PreparedStatements closed automatically.

Technical details

When a JDBC connection is closed by the application (returned to the pool) then the JDBC specification requires all pending statements to be closed as well.

We supported this, but apparently this was not done for all statement types. We fixed this now.

This issue is marked as severity 4 (development use) because we had no real bug reports from any customers. It was something we noticed during a code review.

Changes impacting client API

None.

Bug197253

Suspend/resume should not change local sibling count

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

Description

You can now use @RequiresNew with imported transactions.

Technical details

As explained in this GitHub issue, there were problems when a remote transaction was imported and then subsequently called local logic that was marked with @RequiresNew. As required by the specification of @RequiresNew, this would suspend any active transaction - and resume it later.

Our code had a side effect of suspend/resume that changed the local sibling count.

Sibling counts help detect orphaned invocations (and their transactional updates to persistent storage) that arise out of lost replies. For instance, consider this scenario with services A and B:

1. A starts a transaction.
2. A calls B as part of that transaction.
3. B does work and returns a result.
4. A does not receive the result due to a network timeout (so B now has an orphaned invocation).
5. A tries again, so B performs the changes again and returns a new result (in the same transaction).
6. A commits the transaction thinking it only updated B once.
7. B commits the same transaction with two sets of updates.

This risk here is the different views of A and B regarding the scope of the transaction: A thinks it commits one update to B, whereas B commits two different updates. This can be a problem for data consistency, so we avoid this by keeping sibling counts at B and A. A constructs its sibling count picture with each result it actually receives with its replies from A. Before commit, A passes on the "count" it has for invocations at B, and if B finds that there is no match then it refuses to commit.

This would avoid the problem outlined above, because in step 4 service A will miss a count, so in step 6 service A will pass a count of 1 for service B, whereas B will see 2 and refuses the commit process.

In short, sibling counts have their purpose. However due to a bug, this was affected by a suspend/resume at service B (when it has @RequiresNew logic inside).

Changes impacting client API

You should now be able to configure @RequiresNew on any service that needs it.

Bug197240

Allow spring.jta properties in Spring Boot starter

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

Description

Any spring.jta properties in Spring Boot should now be taken into account.

Technical details

After the Spring Boot team contributed the source code for their Atomikos starter we thought it was safer to ignore any properties with the "legacy" prefix spring.jta.atomikos.properties (in your application.properties file for Spring Boot).

This has proven to confuse users, so we now take such spring.jta properties into account.

Changes impacting client API

Any spring.jta properties in Spring Boot should now be taken into account.

Bug200925

Improve handling of null xaresource

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

Description

We've refined how we deal with lost XA connections during the commit phase.

Technical details

Some connection issues would lead to needless heuristic exceptions during commit, in particular when the commit was 1-phase (where failure to reach the backend results in resource-internal rollback anyway).We have now refined this so there are no needless heuristic exceptions any more in these cases. At the same time, we have also tried to minimise the number of cases where such connection issues remain.

Changes impacting client API

None.

Bug201164

Avoid ConcurrentModificationException during trace logging in the pool

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

Description

You can now use our pools with TRACE logging and get less exceptions.

Technical details

The issue details are described in this GitHub issue.

Changes impacting client API

None.

Issue201646

Spring Boot 2 starter: also add jta and jms versions of Spring Boot's POM to the starter project

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

Description

Unlike Spring Boot 3 support, we did not yet add the JMS and JTA dependencies in the Spring Boot 2 starter.

Technical details

We still have to add the JMS and JTA dependencies in the Spring Boot 2 starter. This is needed because of the removal of transitive dependencies. Until then, you will have to add them yourself.

Free Download

Bug181871

Avoid that ConnectionPoolWithConcurrentValidation grows beyond maxPoolSize

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

Description

We've ported a fix from our commercial release that prevents the pool from exceeding its maxPoolSize.

Technical details

The concurrent pool does not enforce synchronization so when it:

1. checks if the pool can grow and then
2. actually grows it

… a different thread may have done the same and the pool grows too much.

Solution: we've made growPool (with existing synchronized block) check maxSize again, and don't grow if already at the maximum.

Changes impacting client API

None.