Ex­tremeTrans­ac­tions 6.0.113

Re­lease notes for 6.0.113

Fea­ture211078

Add Spring Boot 3.4 starter

You can now use Atomikos with Spring Boot 3.4.

Tech­ni­cal de­tails

Spring Boot 3.4 re­quired a new starter project to make it work with Atomikos.

At­tempt­ing to use Spring Boot 3.4 with the old­er starter project would re­sult in er­rors 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 re­moval of some dep­re­cat­ed meth­ods in org.springframe­work.boot.au­to­con­fig­ure.trans­ac­tion.Trans­ac­tionMan­agerCus­tomiz­ers. A new starter project was need­ed to fix this.

Changes im­pact­ing client API

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

Fea­ture208173

Im­prove er­ror mes­sage when JDBC dri­ver does not re­turn a valid con­nec­tion

You now get a mean­ing­ful er­ror mes­sage when the JDBC dri­ver does not re­turn a valid con­nec­tion.

Tech­ni­cal de­tails

When the JDBC dri­ver does not re­turn a valid con­nec­tion, this would re­sult in a cryp­tic ex­cep­tion 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 re­port that the "Driv­er didn't re­turn a valid Con­nec­tion".

Changes im­pact­ing client API

None.

Fea­ture207950

Avoid un­nec­es­sary XA con­nec­tion re­fresh on shut­down

We now avoid use­less XA con­nec­tion re­fresh­ing on shut­down.

Tech­ni­cal de­tails

The fol­low­ing would hap­pen upon shut­down, when for in­stance the JMS serv­er 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 im­proved / fixed - we now avoid such re­fresh.

Changes im­pact­ing client API

None.

Bug208965

Con­nec­tion pool: make wait­ing for con­nec­tions fair(er)

Sever­i­ty:	4
Af­fect­ed ver­sion(s):	6.0.112

De­scrip­tion

Your getCon­nec­tion re­quests now get the (new) con­nec­tions they de­serve.

Tech­ni­cal de­tails

In our 6.0 re­lease the con­nec­tion pool grows via a sep­a­rate back­ground thread. When getCon­nec­tion finds no avail­able con­nec­tion, it will start wait­ing for this thread to grow the pool and add a new con­nec­tion to it.

The im­ple­men­ta­tion was "un­fair" in that a wait­ing getCon­nec­tion re­quest could (and would) see its new con­nec­tion "hi­jacked" by a dif­fer­ent, lat­er getCon­nec­tion re­quest.

This has now been fixed.

Changes im­pact­ing client API

None.

Bug211208

Tom­cat JNDI fac­to­ry for JDBC and JMS: make it tol­er­ate dou­ble lookups

Sever­i­ty:	4
Af­fect­ed ver­sion(s):	6.0.x, 5.0.x

De­scrip­tion

You can now safe­ly re­peat JNDI lookups for our JDBC and JMS fac­to­ries bound in Tom­cat's JNDI space.

Tech­ni­cal de­tails

There was a race con­di­tion in our code that could lead to re­peat­ed ini­tial­i­sa­tion of JNDI re­sources with the same name, like JDBC data­sources or JMS con­nec­tion fac­to­ries.

This has now been fixed.

Changes im­pact­ing client API

None.

About Sever­i­ty

The sever­i­ty lev­els we use are de­fined in our sup­port terms and con­di­tions.