ExtremeTransactions 6.0.113

Release notes for 6.0.113

Feature211078

Add Spring Boot 3.4 starter

You can now use Atomikos with Spring Boot 3.4.

Technical details

Spring Boot 3.4 required a new starter project to make it work with Atomikos.

Attempting to use Spring Boot 3.4 with the older starter project would result in errors like this:

Caused by: java.lang.NoSuchMethodError: 'void org.springframework.boot.autoconfigure.transaction.TransactionManagerCustomizers.customize(org.springframework.transaction.PlatformTransactionManager)'
  at com.atomikos.spring.AtomikosAutoConfiguration.lambda$transactionManager$0(AtomikosAutoConfiguration.java:84)
  at org.springframework.beans.factory.support.DefaultListableBeanFactory$DependencyObjectProvider.ifAvailable(DefaultListableBeanFactory.java:2382)
  at com.atomikos.spring.AtomikosAutoConfiguration.transactionManager(AtomikosAutoConfiguration.java:84)
  at java.base/java.lang.reflect.Method.invoke(Method.java:580)
  at org.springframework.beans.factory.support.SimpleInstantiationStrategy.lambda$instantiate$0(SimpleInstantiationStrategy.java:171)
  ... 50 more

This was due to Spring's removal of some deprecated methods in org.springframework.boot.autoconfigure.transaction.TransactionManagerCustomizers. A new starter project was needed to fix this.

Changes impacting client API

You can now just use the new starter for your project.

Feature208173

Improve error message when JDBC driver does not return a valid connection

You now get a meaningful error message when the JDBC driver does not return a valid connection.

Technical details

When the JDBC driver does not return a valid connection, this would result in a cryptic exception like this:

java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "this.delegate" is null
                at com.atomikos.util.DynamicProxySupport.getClassLoadersToTry(DynamicProxySupport.java:195) ~[atomikos-util-6.0.112.jar:na]
                at com.atomikos.util.DynamicProxySupport.createDynamicProxy(DynamicProxySupport.java:189) ~[atomikos-util-6.0.112.jar:na]
                at com.atomikos.jdbc.internal.AtomikosNonXAPooledConnection.doCreateConnectionProxy(AtomikosNonXAPooledConnection.java:108) ~[transactions-jdbc-6.0.112.jar:na]
                at com.atomikos.jdbc.internal.AtomikosNonXAPooledConnection.doCreateConnectionProxy(AtomikosNonXAPooledConnection.java:35) ~[transactions-jdbc-6.0.112.jar:na]
                at com.atomikos.datasource.pool.AbstractXPooledConnection.createConnectionProxy(AbstractXPooledConnection.java:101) ~[transactions-jta-6.0.112.jar:na]
                at com.atomikos.datasource.pool.ConnectionPoolWithConcurrentValidation.concurrentlyTryToUse(ConnectionPoolWithConcurrentValidation.java:61) ~[transactions-jta-6.0.112.jar:na]
                at com.atomikos.datasource.pool.ConnectionPoolWithConcurrentValidation.retrieveFirstAvailableConnection(ConnectionPoolWithConcurrentValidation.java:43) ~[transactions-jta-6.0.112.jar:na]
                at com.atomikos.datasource.pool.ConnectionPool.retrieveFirstAvailableConnectionAndGrowPoolIfNecessary(ConnectionPool.java:140) ~[transactions-jta-6.0.112.jar:na]
                at com.atomikos.datasource.pool.ConnectionPool.findOrWaitForAnAvailableConnection(ConnectionPool.java:128) ~[transactions-jta-6.0.112.jar:na]
                at com.atomikos.datasource.pool.ConnectionPool.borrowConnection(ConnectionPool.java:119) ~[transactions-jta-6.0.112.jar:na]
                at com.atomikos.jdbc.internal.AbstractDataSourceBean.getConnection(AbstractDataSourceBean.java:375) ~[transactions-jdbc-6.0.112.jar:na]
                at com.atomikos.jdbc.AtomikosNonXADataSourceBean.getConnection(AtomikosNonXADataSourceBean.java:208) ~[transactions-jdbc-6.0.112.jar:na]

This has now been fixed: we now report that the "Driver didn't return a valid Connection".

Changes impacting client API

None.

Feature207950

Avoid unnecessary XA connection refresh on shutdown

We now avoid useless XA connection refreshing on shutdown.

Technical details

The following would happen upon shutdown, when for instance the JMS server was gone:

Failed to refresh XAResource
com.atomikos.datasource.ResourceException: Error in getting XA resource
        at com.atomikos.datasource.xa.jms.JmsTransactionalResource.refreshXAConnection(JmsTransactionalResource.java:83) ~[!/:?]
        at com.atomikos.datasource.xa.XATransactionalResource.refreshXAResource(XATransactionalResource.java:413) ~[!/:?]
        at com.atomikos.datasource.xa.XATransactionalResource.getXAResource(XATransactionalResource.java:227) ~[!/:?]
        at com.atomikos.datasource.xa.XATransactionalResource.isSameRM(XATransactionalResource.java:317) ~[!/:?]
        at com.atomikos.datasource.xa.XATransactionalResource.equals(XATransactionalResource.java:430) ~[!/:?]
        at java.util.Vector.indexOf(Vector.java:413) ~[?:1.8.0_381]
        at java.util.Vector.indexOf(Vector.java:387) ~[?:1.8.0_381]
        at java.util.Vector.removeElement(Vector.java:646) ~[?:1.8.0_381]
        at java.util.Vector.remove(Vector.java:804) ~[?:1.8.0_381]
        at com.atomikos.icatch.config.Configuration.removeResource(Configuration.java:263) ~[!/:?]
        at com.atomikos.jms.AtomikosConnectionFactoryBean.close(AtomikosConnectionFactoryBean.java:597) ~[!/:?]

This has been improved / fixed - we now avoid such refresh.

Changes impacting client API

None.

Bug208965

Connection pool: make waiting for connections fair(er)

Severity:	4
Affected version(s):	6.0.112

Description

Your getConnection requests now get the (new) connections they deserve.

Technical details

In our 6.0 release the connection pool grows via a separate background thread. When getConnection finds no available connection, it will start waiting for this thread to grow the pool and add a new connection to it.

The implementation was "unfair" in that a waiting getConnection request could (and would) see its new connection "hijacked" by a different, later getConnection request.

This has now been fixed.

Changes impacting client API

None.

Bug211208

Tomcat JNDI factory for JDBC and JMS: make it tolerate double lookups

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

Description

You can now safely repeat JNDI lookups for our JDBC and JMS factories bound in Tomcat's JNDI space.

Technical details

There was a race condition in our code that could lead to repeated initialisation of JNDI resources with the same name, like JDBC datasources or JMS connection factories.

This has now been fixed.

Changes impacting client API

None.

About Severity

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