Re­lease notes for Ex­tremeTrans­ac­tions 6.1.116

Fea­ture211440

Im­prove mi­crom­e­ter met­rics sup­port for the pool us­age: add getPer­cent­ageOfPoolCa­pac­i­tyUsed

You can now see the pool's per­cent­age used (wrt its ca­pac­i­ty) in our Mi­crom­e­ter sup­port mod­ule.

Tech­ni­cal de­tails

The abil­i­ty to see the pool's per­cent­age used (wrt its ca­pac­i­ty) was al­ready present in our JMX mod­ule, but not in our Mi­crom­e­ter sup­port. This has now been added.

Changes im­pact­ing client API

None.

Bug214569

Fix pom de­pen­den­cy for Spring Boot 3.4 starter

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

De­scrip­tion

You can now use the new Spring Boot 3.4 starter.

Tech­ni­cal de­tails

The mod­ule trans­ac­tions-spring-boot3.4-starter had a de­pen­den­cy on com.atom­ikos.trans­ac­tions-spring-boot3, where­as it should have had a de­pen­den­cy on com.atom­ikos.trans­ac­tions-spring-boot3.4. This has been fixed.

Changes im­pact­ing client API

None.

Bug212902

Im­prove er­ror mes­sage on en­list / time­out

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

De­scrip­tion

The er­ror mes­sage on po­ten­tial time­outs is now bet­ter.

Tech­ni­cal de­tails

Some cas­es would re­port an er­ror like "The trans­ac­tion has timed out - try in­creas­ing the time­out if need­ed" when in fact the cause was a wrong state of the trans­ac­tion.

This has been im­proved to also show state in­for­ma­tion:

"The trans­ac­tion has po­ten­tial­ly timed out (state: " + state + ") - try in­creas­ing the time­out if need­ed"

Changes im­pact­ing client API

None.

Bug212919

Im­prove thread-safe­ty of CheckedEx­port­ingTrans­ac­tionMan­ag­er

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

De­scrip­tion

The im­ple­men­ta­tion of this class is now safer for mul­ti-thread­ed use.

Tech­ni­cal de­tails

The at­tribute pend­ingRe­questSyn­chro­ni­sa­tion used to be a HashMap and is now a Con­cur­ren­tHashMap.

Changes im­pact­ing client API

None.

Bug212877

Tom­cat ex­am­ples: fix port num­ber in the README

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

De­scrip­tion

The port num­ber has been cor­rect­ed in the README of the tom­cat ex­am­ples.

Tech­ni­cal de­tails

The README file would con­tain port 8080 in­stead of 8888. This has been fixed.

Changes im­pact­ing client API

None.

Bug212878

Up­date tom­cat ex­am­ples to make dock­er in­clude the lat­est re­lease

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

De­scrip­tion

The new Tom­cat ex­am­ples should now in­clude the right Atomikos re­lease.

Tech­ni­cal de­tails

Due to an is­sue with maven plu­g­ins, the ex­am­ples would not al­ways ship the right Atomikos re­lease. This has now been fixed.

Changes im­pact­ing client API

None.

Is­sue214480

Dis­able OSGi ex­am­ples build

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

De­scrip­tion

The OSGi ex­am­ples are now skipped dur­ing the build.

Tech­ni­cal de­tails

The OSGi ex­am­ples used bun­dle de­pen­den­cies host­ed on a Spring repos­i­to­ry site that has been dis­con­tin­ued. This made the build fail. Un­til we find a so­lu­tion, we had to dis­able this mod­ule dur­ing the build (or re­leas­es would be blocked).

Is­sue215322

Zip files with ex­am­ple projects not up­loaded cor­rect­ly

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

De­scrip­tion

The zip files with ex­am­ple projects failed to up­load.

Tech­ni­cal de­tails

When try­ing to down­load the ex­am­ple projects from the in­stal­la­tion page(s) you will get "404 Not Found" er­rors. We are look­ing into it but de­cid­ed not to let this block a main­te­nance re­lease like this one.

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.

Fea­ture200360

Sub­scrip­tion files are now re­quired for pro­duc­tion use

De­scrip­tion

We now re­quire cus­tomers to in­stall sub­scrip­tion files for pro­duc­tion use, sim­i­lar to what we do in 6.0.

Tech­ni­cal de­tails

We've had some bad ex­pe­ri­ences with sub­scrip­tions pur­chased via re­sellers / in­ter­me­di­aries, that were first used by a de­vel­op­ment team, then moved onto oth­er teams in pro­duc­tion with­out us be­ing able to keep track. This has lead to un­pleas­ant ex­pe­ri­ences for both our cus­tomers and our­selves.

For more de­tails, see this doc­u­men­ta­tion page.

Changes im­pact­ing client API

You need to in­stall 2 files as ex­plained on the doc­u­men­ta­tion page men­tioned above. Note: de­vel­op­ment or test­ing use does not need sub­scrip­tion files.

Fea­ture201309

De­tect vul­ner­a­ble de­pen­den­cies on class­path

De­scrip­tion

We now help you find out about known vul­ner­a­ble maven de­pen­den­cies that your ap­pli­ca­tion is us­ing.

Tech­ni­cal de­tails

With cur­rent hack­er ef­forts mov­ing more and more into the ap­pli­ca­tion stack via vul­ner­a­ble open source de­pen­den­cies, we no­tice cus­tomers are get­ting wor­ried (or fac­ing au­dits of their ap­pli­ca­tions). Log4j, any­one?

Our ap­proach has been two-fold:

• We avoid 3rd par­ty de­pen­den­cies so you can't pull them in by ac­ci­dent, and
• We now also de­tect known vul­ner­a­ble 3rd par­ty maven de­pen­den­cies on your ap­pli­ca­tion's class­path

Start­ing in the near fu­ture, ex­pect more and more "se­cu­ri­ty up­dates" in that re­spect.

Changes im­pact­ing client API

None.

Bug197240

Al­low spring.jta prop­er­ties in Spring Boot starter

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

De­scrip­tion

Any spring.jta prop­er­ties in Spring Boot should now be tak­en into ac­count.

Tech­ni­cal de­tails

After the Spring Boot team con­tributed the source code for their Atomikos starter we thought it was safer to ig­nore any prop­er­ties with the "lega­cy" pre­fix spring.jta.atom­ikos.prop­er­ties (in your ap­pli­ca­tion.prop­er­ties file for Spring Boot).

This has proven to con­fuse users, so we now take such spring.jta prop­er­ties into ac­count.

Changes im­pact­ing client API

Any spring.jta prop­er­ties in Spring Boot should now be tak­en into ac­count.

Bug197505

Avoid that de­faults in the Spring Boot starter over­ride jta.prop­er­ties

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

De­scrip­tion

You can now count on the prop­er­ty val­ues from jta.prop­er­ties to be tak­en into ac­count even with Spring Boot.

Tech­ni­cal de­tails

The Atomikos JTA prop­er­ties im­ple­men­ta­tion in our Spring Boot starter would de­fine de­fault val­ues for many prop­er­ties, mean­ing that their val­ue spec­i­fied jta.prop­er­ties would not be tak­en into ac­count. This has now been fixed.

Changes im­pact­ing client API

Your prop­er­ties spec­i­fied in jta.prop­er­ties should now work.

Bug197362

Clar­i­fy mes­sage if rest port not set in client

Sever­i­ty:	1/2/3/4
Af­fect­ed ver­sion(s):	5.0.x

De­scrip­tion

You can now count on a bet­ter er­ror mes­sage when the AtomikosRestPort URL is not set (for trans­ac­tions across re­mot­ing calls).

Tech­ni­cal de­tails

When the AtomikosRestPort URL was not set, the client tem­plate would re­port a mis­lead­ing mes­sage say­ing that there is no trans­ac­tion for the thread. In­stead, the root cause is a URL that is miss­ing - so we fixed that for you.

Changes im­pact­ing client API

None.

Bug197506

Sup­port di­a­mond case ar­chi­tec­tures for read­On­ly re­mot­ing

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

De­scrip­tion

You can now use tran­si­tive read­On­ly re­mot­ing trans­ac­tions in all cas­es.

Tech­ni­cal de­tails

As out­lined in this GitHub is­sue there was a prob­lem with read­On­ly in­vo­ca­tions when:

• the same shared ser­vice was called over dif­fer­ent paths, and
• all in­vo­ca­tions were read­On­ly

This is known as a "di­a­mond case" be­cause the in­vo­ca­tion di­a­gram looks like a di­a­mond.

This is­sue has been fixed in the fol­low­ing way: our prod­uct will now avoid the read­On­ly op­ti­mi­sa­tion in this spe­cif­ic sce­nario. This is still cor­rect, at a mi­nor per­for­mance over­head in the ex­ot­ic cas­es where this does hap­pen.

Changes im­pact­ing client API

None.

Bug197253

Sus­pend/re­sume should not change lo­cal sib­ling count

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

De­scrip­tion

You can now use @Re­quiresNew with im­port­ed trans­ac­tions.

Tech­ni­cal de­tails

As ex­plained in this GitHub is­sue, there were prob­lems when a re­mote trans­ac­tion was im­port­ed and then sub­se­quent­ly called lo­cal log­ic that was marked with @Re­quiresNew. As re­quired by the spec­i­fi­ca­tion of @Re­quiresNew, this would sus­pend any ac­tive trans­ac­tion - and re­sume it lat­er.

Our code had a side ef­fect of sus­pend/re­sume that changed the lo­cal sib­ling count.

Si­b­ling counts help de­tect or­phaned in­vo­ca­tions (and their trans­ac­tion­al up­dates to per­sis­tent stor­age) that arise out of lost replies. For in­stance, con­sid­er this sce­nario with ser­vices A and B:

1. A starts a trans­ac­tion.
2. A calls B as part of that trans­ac­tion.
3. B does work and re­turns a re­sult.
4. A does not re­ceive the re­sult due to a net­work time­out (so B now has an or­phaned in­vo­ca­tion).
5. A tries again, so B per­forms the changes again and re­turns a new re­sult (in the same trans­ac­tion).
6. A com­mits the trans­ac­tion think­ing it only up­dat­ed B once.
7. B com­mits the same trans­ac­tion with two sets of up­dates.

This risk here is the dif­fer­ent views of A and B re­gard­ing the scope of the trans­ac­tion: A thinks it com­mits one up­date to B, where­as B com­mits two dif­fer­ent up­dates. This can be a prob­lem for data con­sis­ten­cy, so we avoid this by keep­ing sib­ling counts at B and A. A con­structs its sib­ling count pic­ture with each re­sult it ac­tu­al­ly re­ceives with its replies from A. Be­fore com­mit, A pass­es on the "count" it has for in­vo­ca­tions at B, and if B finds that there is no match then it re­fus­es to com­mit.

This would avoid the prob­lem out­lined above, be­cause in step 4 ser­vice A will miss a count, so in step 6 ser­vice A will pass a count of 1 for ser­vice B, where­as B will see 2 and re­fus­es the com­mit process.

In short, sib­ling counts have their pur­pose. How­ev­er due to a bug, this was af­fect­ed by a sus­pend/re­sume at ser­vice B (when it has @Re­quiresNew log­ic in­side).

Changes im­pact­ing client API

You should now be able to con­fig­ure @Re­quiresNew on any ser­vice that needs it.

Bug211208

Avoid init-ing con­nec­tion fac­to­ry twice or more on Tom­cat JNDI lookups

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

De­scrip­tion

You should now be able to per­form any num­ber of JNDI lookups in Tom­cat with­out get­ting warn­ings about the re­source al­ready ex­ist­ing with the same name.

Tech­ni­cal de­tails

Dur­ing JNDI lookups, Tom­cat ap­pli­ca­tions would some­times get warn­ings like be­low due to a race con­di­tion. This has been fixed.

WARNING: Cannot initialize AtomikosConnectionFactoryBean
java.lang.IllegalStateException: Another resource already exists with name XAConnectionFactory - pick a different name
      at com.atomikos.icatch.config.Configuration.addResource(Configuration.java:241)
      at com.atomikos.jms.AtomikosConnectionFactoryBean.doInit(AtomikosConnectionFactoryBean.java:440)
      at com.atomikos.jms.AtomikosConnectionFactoryBean.init(AtomikosConnectionFactoryBean.java:354)
      at com.atomikos.jms.AtomikosConnectionFactoryBean.createConnection(AtomikosConnectionFactoryBean.java:620)

Changes im­pact­ing client API

None.