Fea­ture207056

Im­proved core class­es for con­cur­ren­cy / thread­ing

You can now ben­e­fit from re­duced syn­chro­ni­sa­tion over­head thanks to con­cur­rent maps us­age in our core class­es.

Tech­ni­cal de­tails

We've added 2 new im­ple­men­ta­tion class­es: De­fault­Trans­ac­tionSer­vice and De­fault­Com­pos­iteTrans­ac­tionMan­ag­er. Th­ese com­ply with our new­ly doc­u­ment­ed Con­cur­ren­cy Model for cor­rect­ness in mul­ti-thread­ed ap­pli­ca­tions. We now also use con­cur­rent maps thanks to this this con­tri­bu­tion on github.

The new De­fault­Trans­ac­tionSer­vice also has bet­ter / sim­pler shut­down log­ic for the trans­ac­tion ser­vice.

Changes im­pact­ing client API

This fea­ture can (for now) be tog­gled with a flag in jta.prop­er­ties:

   om.atomikos.icatch.feature.207056 = true 

This is en­abled by de­fault be­cause we are con­fi­dent it works bet­ter than be­fore. If you ex­pe­ri­ence prob­lems af­ter up­grad­ing, set this to false...

Fea­ture203242

Retry file lock on start­up

You can now shift Ku­ber­netes pods by start­ing a new pod while the old one is still ter­mi­nat­ing.

Tech­ni­cal de­tails

In Ku­ber­netes en­vi­ron­ments pods might be ter­mi­nat­ed and shift­ed to oth­er nodes. Be­cause of this the con­fig­ured log path might be in use if the old pod is about to ter­mi­nate and the new one is start­ing up. To be able to use the same LogFileLock we now of­fer retry at­tempts for the new pod which is try­ing to ac­quire the lock.

Changes im­pact­ing client API

None, we have rea­son­able de­fault con­fig­u­ra­tion prop­er­ties in JTA Prop­er­ties, pre­fixed with com.atom­ikos.icatch.log_lock­_ac­qui­si­tion.

Fea­ture201646

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

You can now use the same JTA and JMS de­pen­den­cy ver­sions of Spring Boot's rather than the ones we spec­i­fy.

Tech­ni­cal de­tails

For Spring Boot 2 we used to spec­i­fy a par­tic­u­lar ver­sion for each of JTA and JMS. This would over­ride the ver­sions that Spring Boot prefers. We no longer do this.

Changes im­pact­ing client API

None.

Fea­ture207758

Ex­am­ples for Hiber­nate 7

You can now check the ex­am­ples for Hiber­nate 7.

Tech­ni­cal de­tails

We've added work­ing sam­ples for Hiber­nate 7.

Bug202474

Re­fine ex­cep­tion mes­sage when cre­at­ing a JDBC state­ment fails

Sever­i­ty:	3
Af­fect­ed ver­sion(s):	6.O.x, 5.0.x

De­scrip­tion

You can now ex­pect more ac­cu­rate ex­cep­tion mes­sages when cre­at­ing a JDBC state­ment fails

Tech­ni­cal de­tails

We used to have one gener­ic ex­cep­tion mes­sage when a state­ment could not be cre­at­ed, each time sug­gest­ing a time­out of the trans­ac­tion. This was con­fus­ing if the real rea­son was, for in­stance, the trans­ac­tion hav­ing been marked for roll­back only.

The code has been re­fined 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 im­pact­ing client API

None.

Bug202466

In­ter­posed syn­chro­ni­sa­tion in­stances not called on reg­u­lar roll­back

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

De­scrip­tion

In­ter­posed syn­chro­ni­sa­tion in­stances are now called on reg­u­lar roll­back also.

Tech­ni­cal de­tails

See this github is­sue for de­tails.

Changes im­pact­ing client API

None.

Bug208965

Bug in bor­row­ing con­nec­tion: make wait­ing for avail­able con­nec­tions fair(er)

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

De­scrip­tion

Get­ting a new con­nec­tion is now more ef­fi­cient.

Tech­ni­cal de­tails

De­tails are ex­plained in this github is­sue.

Changes im­pact­ing client API

None.

Bug209260

Ex­pose AtomikosSQLEx­cep­tion in pub­lic pack­age (for OSGi)

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

De­scrip­tion

The class AtomikosSQLEx­cep­tion was not ex­posed as pub­lic in OSGi.

Tech­ni­cal de­tails

The class AtomikosSQLEx­cep­tion was not ex­posed as pub­lic in OSGi be­cause it was in an "in­ter­nal" pack­age. This class has been moved to a pub­lic pack­age in­stead, so it can be used with OSGi.

Changes im­pact­ing client API

You have to change the im­ports when your code ref­er­ences this ex­cep­tion.

Bug207055

Bug in time­out/roll­back of lo­cal sub trans­ac­tion fol­lowed by com­mit of its par­ent

Sever­i­ty:	3
Af­fect­ed ver­sion(s):	5.0.x, 6.0.x and pri­or (dec­o­rat­ed) re­leas­es

De­scrip­tion

Time­out / roll­back of a sub­trans­ac­tion no longer ap­pears as a com­mit to the par­ent trans­ac­tion.

Tech­ni­cal de­tails

Time­out with sub­se­quent roll­back of a sub­trans­ac­tion would in­ter­fere with a lat­er com­mit of the par­ent trans­ac­tion: the state han­dler for the sub­trans­ac­tion would er­ro­neous­ly re­ply with READONLY upon 2PC pre­pare. This would make it seem to the par­ent trans­ac­tion as though com­mit may pro­ceed. We've fixed this by check­ing for time­out upon pre­pare of a sub­trans­ac­tion. Most peo­ple are not us­ing sub­trans­ac­tion func­tion­al­i­ty, but those who do will ben­e­fit from this fix.

Changes im­pact­ing client API

None.

Bug207046

Im­prove 2-phase com­mit for im­port­ed trans­ac­tion to align with the new con­cur­ren­cy mod­el

Sever­i­ty:	3
Af­fect­ed ver­sion(s):	5.0.x, 6.0.x and pri­or (dec­o­rat­ed) re­leas­es

De­scrip­tion

We im­proved the way im­port­ed trans­ac­tions are han­dled in the case of net­work time­outs - so it aligns with our con­cur­ren­cy mod­el.

Tech­ni­cal de­tails

This re­lease in­cludes an im­proved con­cur­ren­cy im­ple­men­ta­tion (as per fea­ture 207056 above), along with a new­ly doc­u­ment­ed con­cur­ren­cy mod­el as shown in Con­cur­ren­cy Model. We've up­dat­ed the han­dling of im­port­ed trans­ac­tions to be con­sis­tent with the new con­cur­ren­cy mod­el. In par­tic­u­lar, the fol­low­ing sce­nario has been im­proved:

• A re­mote client prop­a­gates a trans­ac­tion to your ser­vice, pos­si­bly on a num­ber of times on dif­fer­ent in­vo­ca­tions.
• The last in­vo­ca­tion "I" ap­pears to "fail" at the re­mote client due to a net­work time­out, but the in­vo­ca­tion as ac­tu­al­ly still ac­tive at your ser­vice.
• The re­mote client de­cides to ter­mi­nate the trans­ac­tion by ei­ther com­mit (which is pos­si­ble if "I" is con­sid­ered op­tion­al) or roll­back.
• Depend­ing on the com­plex­i­ty of the re­mote trans­ac­tion, this will lead to ei­ther of an in­com­ing "PC": pre­pare, roll­back or 1-phase com­mit call in your ser­vice.
• The clas­si­cal way we dealt with this was in­stant roll­back trig­gered by the in­com­ing "2PC", but this vi­o­lates our new con­cur­ren­cy mod­el.
• So we now let the pend­ing ac­tive in­vo­ca­tion do the roll­back in­stead - in line with the con­cur­ren­cy mod­el.

Changes im­pact­ing client API

None.

Bug207146

High mem­o­ry con­sump­tion due to adding JDBC state­ments mul­ti­ple times to the same list

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

De­scrip­tion

Creat­ing many JDBC state­ments no longer leads to high mem­o­ry con­sump­tion.

Tech­ni­cal de­tails

For tech­ni­cal rea­sons we keep a "cached" col­lec­tion of JDBC state­ments. Due to a bug, such state­ments were added mul­ti­ple times to a list. We fixed this by:

• Chang­ing the list to a Set, and
• Re­mov­ing the lines of code that added state­ments more than once.

Changes im­pact­ing client API

None.

Bug209259

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

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

De­scrip­tion

We im­proved the tread-safe­ty of CheckedEx­port­ingTrans­ac­tionMan­ag­er in mod­ule trans­ac­tions-re­mot­ing.

Tech­ni­cal de­tails

We changed the use of a HashMap to a Con­cur­ren­tHashMap for pend­ing re­quest syn­chro­ni­sa­tion in­stances.

Changes im­pact­ing client API

None.

Bug202750

Con­nec­tionPool: end­less loop on in­ter­rupt dur­ing wait­ForCon­nec­tion

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

De­scrip­tion

In­ter­rup­tions dur­ing Spring Boot shut­down are now han­dled bet­ter by the con­nec­tion pool.

Tech­ni­cal de­tails

Full de­tails as dis­closed in the orig­i­nal re­port:

We ex­pe­ri­enced a some­what strange be­hav­iour with Atomikos in a sit­u­a­tion, where our ap­pli­ca­tion (Spring Boot) is shut­ting down while some threads are wait­ing for a con­nec­tion. In this shut­down-sit­u­a­tion, Spring Boot sends an 'in­terupt' to all run­ning threads. The Atomikos Con­nec­tionPool method 'wait­ForAtLeast­OneA­vail­ableCon­nec­tion()' han­dles this In­ter­rupt­edEx­cep­tion by in­vok­ing the In­terupt­edEx­cep­tionHelper. This in turn logs the ex­cep­tion and re-in­ter­rupts the thread. This is the cor­rect pat­tern to in­ter­rupt pos­si­ble fur­ther waits in the call stack.

But the method does not leave the while-loop. This caus­es a loop for the re­main­ing bor­rowCon­nec­tionTime­out, lead­ing to a very large amount of ex­cep­tion logs.

Changes im­pact­ing client API

None.

Bug210111

Miss­ing jar in eval down­load: trans­ac­tions-tom­cat-jakar­ta

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

De­scrip­tion

You can now use the Tom­cat Jakar­ta func­tion­al­i­ty in the free tri­al down­load.

Tech­ni­cal de­tails

The rel­e­vant jar file for this was miss­ing from the eval­u­a­tion zip file. It has now been added.

Is­sue202334

Mod­i­fy Tom­cat ex­am­ples to use Dock­er

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

De­scrip­tion

The Tom­cat ex­am­ples have been mod­i­fied to user Dock­er, but this does not work on all plat­forms yet.

Tech­ni­cal de­tails

The Dock­er im­age gen­er­at­ed to run the Tom­cat ex­am­ples con­tains a Java JDK that is not bi­na­ry com­pat­i­ble with all plat­forms yet.

Fea­ture208965

Im­prove fair­ness even more while grow­ing the con­nec­tion pool

Re­leas­es 6.0.110 and 6.0.111 of­fered a fair­er way of grow­ing the con­nec­tion pool. This has been op­ti­mised fur­ther.

Tech­ni­cal de­tails

The two pri­or re­leas­es at­tempt­ed to of­fer a fair­er way of grow­ing the con­nec­tion pool, so a thread that re­quests an ex­tra con­nec­tion could also use it. How­ev­er, there the al­go­rithm was still not as good as it could be, be­cause it did the fol­low­ing:

1. Thread A re­quests grow­ing the pool
2. The pool adds an ex­tra con­nec­tion
3. The ex­tra con­nec­tion is put into the pool of avail­able con­nec­tions
4. Thread A then quick­ly fetch­es the new con­nec­tion

While this per­formed bet­ter than be­fore, this still al­lowed for an­oth­er thread to hi­jack the con­nec­tion be­tween steps 3 and 4.

We now changed this to the fol­low­ing:

1. Thread A re­quests grow­ing the pool
2. The pool adds an ex­tra con­nec­tion
3. The pool marks the con­nec­tion as be­ing used
4. The ex­tra con­nec­tion is put into the pool of avail­able con­nec­tions
5. The ex­tra con­nec­tion is re­turned for Thread A to use

The ex­tra step 3 im­plies that no oth­er thread can take the con­nec­tion af­ter step 4. Thus, Thread A is al­ways able to use the new con­nec­tion.

Changes im­pact­ing client API

None.

Is­sue202334

Mod­i­fy Tom­cat ex­am­ples to use Dock­er

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

De­scrip­tion

The Tom­cat ex­am­ples have been mod­i­fied to user Dock­er, but this does not work on all plat­forms yet.

Tech­ni­cal de­tails

The Dock­er im­age gen­er­at­ed to run the Tom­cat ex­am­ples con­tains a Java JDK that is not bi­na­ry com­pat­i­ble with all plat­forms yet.

Bug208965

Fix race con­di­tion in new pool growth al­go­rithm

Sever­i­ty:	2
Af­fect­ed ver­sion(s):	6.0.110

De­scrip­tion

The im­prove­ment shipped as part of re­lease 6.0.110 con­tained a bug that cause race con­di­tions on con­cur­rent pool us­age. This is no longer the case;

Tech­ni­cal de­tails

The im­prove­ment that made grow­ing the pool fair­er for con­cur­rent wait­ing threads con­tained a bug that led to at­tempts to use the same con­nec­tion in two dif­fer­ent threads, lead­ing to ex­cep­tions 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 im­pact­ing client API

None.

Is­sue202334

Mod­i­fy Tom­cat ex­am­ples to use Dock­er

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

De­scrip­tion

The Tom­cat ex­am­ples have been mod­i­fied to user Dock­er, but this does not work on all plat­forms yet.

Tech­ni­cal de­tails

The Dock­er im­age gen­er­at­ed to run the Tom­cat ex­am­ples con­tains a Java JDK that is not bi­na­ry com­pat­i­ble with all plat­forms yet.

Added sup­port for Jakar­ta EE, Spring Boot 3 and Hiber­nate 6.

Up­grad­ing from 5.0 to 6.0

This re­lease was very hard to do. Not be­cause we want­ed many new fea­tures in­clud­ed (there are not that many, ac­tu­al­ly), but rather be­cause it was a bal­anc­ing act be­tween sta­bil­i­ty / back­wards com­pat­i­bil­i­ty and new "break­ing change" emerg­ing plat­forms (specif­i­cal­ly: Spring Boot 3, Hiber­nate 6 and their de­pen­den­cies on Jakar­taEE and very re­cent Java ver­sions).

We think we did a good job: just like the pre­vi­ous re­lease 5.0, this new re­lease can run on "good old" Java 8 for most mod­ules, ex­cept for Spring Boot 3 in­te­gra­tion (which re­quires Java 17 as per Spring Boot) and Hiber­nate 6. So if your ap­pli­ca­tion worked with re­lease 5.0 then it should still work, pro­vid­ed that you do the fol­low­ing:

Add ex­tra de­pen­den­cies ex­plic­it­ly to your POM

We now sup­port both javax and jakar­ta name­spaces for the Java en­ter­prise APIs, by of­fer­ing reg­u­lar jars as well as "jakar­ta" jars (with the cor­re­spond­ing clas­si­fi­er in the jar names). Th­ese jakar­ta jars are gen­er­at­ed at build time with the Eclipse trans­former util­i­ty.

In or­der to do this, we had to break the tran­si­tive de­pen­den­cy mech­a­nism (which, in­ci­den­tal­ly, also avoids pulling in vul­ner­a­ble 3rd par­ty code libs). So: ex­cept for Spring Boot 3 apps, this means that you will now have to add the fol­low­ing de­pen­den­cy to your pom file (or you risk fac­ing ClassNotFoundEx­cep­tions):

The tra­di­tion­al 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 jakar­ta 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>

Over­ride the new JMS be­hav­iour to re­vert to pri­or re­lease be­hav­iour

We now sup­port JMS 2. This re­quired some changes to the JMS ses­sion cre­ation be­hav­iour, so if you rely on the "old" JMS be­hav­iour then set the fol­low­ing prop­er­ty on the AtomikosCon­nec­tionFac­to­ryBean:

     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 de­tails, see the javadoc of the AtomikosCon­nec­tionFac­to­ryBean class.

Drop any reapTime­out prop­er­ty

We've re­moved reap func­tion­al­i­ty from the pool, so re­move any reapTime­out prop­er­ty in your data­source or con­nec­tion fac­to­ry con­fig.

De­tailed re­lease notes

If you like the nit­ty grit­ty de­tails, then the fol­low­ing sec­tions are for you!

Fea­ture199869

Spring Boot 3 Starter

We added a starter for Spring Boot 3.

Tech­ni­cal de­tails

Spring Boot 3 has made a "big bang" up­grade to Jakar­ta EE and Java 17, with all com­pli­ca­tions in­volved. You can now use Atomikos with Spring Boot 3 by means of our new Spring Boot 3 starter mod­ule.

Changes im­pact­ing client API

Spring Boot 3 re­quires Java 17 or high­er, plus all Jakar­taEE li­braries (and for course Atomikos re­leas­es 6.0 or high­er). Note that this means you will also need Jakar­taEE JMS dri­vers, and Jakar­taEE per­sis­tence providers. Hur­ray.

You need the fol­low­ing de­pen­den­cy to use Spring Boot 3:

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

For the Jakar­taEE JMS and JTA APIs: we've added those to the Spring Boot 3 starter mod­ule al­ready - so you don't have to both­er.

Fea­ture197500

Sup­port Jakar­taEE li­braries and pack­ages

De­scrip­tion

We now also sup­port Jakar­taEE (in ad­di­tion to the "old" JEE with javax name­spaces).

Tech­ni­cal de­tails

All rel­e­vant mod­ules are now avail­able in both a tra­di­tion­al vari­ant and a Jakar­taEE vari­ant, the lat­ter gen­er­at­ed with the Eclipse trans­former util­i­ty dur­ing the build. Jakar­taEE jars car­ry the same name as their tra­di­tion­al coun­ter­parts, but have the ad­di­tion­al clas­si­fi­er "jakar­ta" in the jar file name to dis­tin­guish them.

The choice for this strat­e­gy was heav­i­ly dri­ven by our de­sire to still sup­port Java 8 ap­pli­ca­tions that can't up­grade to Java 17 or Jakar­taEE right now.

The pre­vi­ous state­ment prob­a­bly de­serves some ex­pla­na­tion: af­ter some ini­tial at­tempts it was painful­ly clear to us that up­grad­ing from Java 8 to Java 17 is noth­ing short of a night­mare.

[Oh and by the way, we fig­ure that this is the rea­son why ex­tend­ed sup­port for Java 8 is avail­able un­til 2030, the longest of all Java ver­sions at the time of pub­li­ca­tion. Yes, that means Java 8 should be sup­port­ed for longer than Java 17 - go fig­ure that!]

Our cho­sen ap­proach should al­low ex­ist­ing in­stal­la­tions to up­grade to our 6.0 re­lease with­out the need to up­grade to Jakar­taEE and/or Java 17 at the same time.

Past ex­pe­ri­ence with our cus­tomers has shown that even a "sim­ple" up­grade from Java 6 to Java 8 can be a huge road­block - es­pe­cial­ly if the de­vel­op­ment team is gone and only op­er­a­tions teams are left. So we pre­fer to keep up­grad­ing a seam­less and straight­for­ward process, with­out re­quir­ing need­less Java up­dates at the same time. We are sure that you will ap­pre­ci­ate that.

The "down­side" of this choice is that you can no longer count on tran­si­tive de­pen­den­cies as much as you did, be­cause many mod­ules now have 2 vari­ants avail­able (and hence the tran­si­tive de­pen­den­cies would not nec­es­sar­i­ly match the right vari­ant). While this may seem a dis­ad­van­tage, it ac­tu­al­ly in­creas­es se­cu­ri­ty be­cause there are no longer tran­si­tive de­pen­den­cies on 3rd par­ty jars ei­ther (so you avoid pulling in vul­ner­a­bil­i­ties).

So: you have to add some de­pen­den­cies man­u­al­ly that were tran­si­tive be­fore. But the ef­fort re­quired is sig­nif­i­cant­ly low­er than the ef­fort it would take to up­grade your code base to­wards Java 17 and Jakar­taEE all at once.

Changes im­pact­ing client API

As ex­plained in the up­grade sec­tion above: you need to de­clare some ex­tra de­pen­den­cies. Also, you have to be care­ful to use the right com­bi­na­tion of Jakar­ta-en­abled jars in your ap­pli­ca­tion. To this end, we have de­fined BOM files that list all the jars de­signed to work to­geth­er:

• trans­ac­tions-es­sen­tials ver­sus trans­ac­tions-es­sen­tials-jakar­ta
• ex­treme-trans­ac­tions ver­sus ex­treme-trans­ac­tions-jakar­ta

You can check these BOMs for in­spi­ra­tion on which jars to use / com­bine in your ap­pli­ca­tion. If you are cu­ri­ous where to find them: check groupId=com.atom­ikos and ar­ti­fac­tId=name_of_BOM_­file.

Fea­ture199608

Hiber­nate 6 sup­port

De­scrip­tion

You can now eas­i­ly use Hiber­nate 6 in com­bi­na­tion with our prod­uct!

Tech­ni­cal de­tails

Hiber­nate 6 is also in the Jakar­taEE camp, so of course you need Jakar­taEE sup­port to be able to use it. Well, as we've ex­plained above: we have done just that.

To use Hiber­nate 6, it suf­fices to use trans­ac­tions-hi­ber­nate4 in the jakar­ta flavour.

For a work­ing sam­ple: check the sup­plied ex­am­ples project called ex­am­ples-hi­ber­nate6 or see the sum­ma­ry POM snip­pet be­low.

Changes im­pact­ing client API

No real changes are need­ed, but you do have to add the cor­rect POM de­pen­den­cies:

      <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 Hiber­nate 6 de­pen­den­cies them­selves - but we'll leave that up to you...

Fea­ture85601

JMS 2.0 sup­port

De­scrip­tion

We now have (min­i­mal) sup­port for JMS 2.0.

Tech­ni­cal de­tails

As re­quired by Jakar­taEE and Spring Boot 3, we need­ed some sup­port for JMS 2.0. For the sake of re­leas­ing on time, this sup­port is only par­tial: we do not yet sup­port the new JMSCon­text API. Spring Boot 3 does not seem to need it, so that should be fine for now. At­tempt­ing to call any of the cre­ateCon­text meth­ods on the AtomikosCon­nec­tionFac­to­ryBean will throw Un­sup­port­edOper­a­tionEx­cep­tion.

Changes im­pact­ing client API

Ses­sion cre­ation be­hav­iour has changed due to the clar­i­fi­ca­tion of ses­sion cre­ation be­hav­iour in JMS 2.0 (which is in­com­pat­i­ble with what we had in pri­or re­leas­es). As you can see in the ta­ble be­low, the dif­fer­ences are in the com­bined in­ter­pre­ta­tion of:

• a JTA trans­ac­tion be­ing present on the call­ing thread or not,
• the val­ue set for lo­calTrans­ac­tionMode and
• the val­ue of the ses­sionTrans­act­ed flag when cre­at­ing a ses­sion.

Pri­or to JMS 2.0, ses­sion cre­ation had some fuzzy bor­der cas­es where the in­ter­pre­ta­tion was left to the par­ty im­ple­ment­ing the specs (like Atomikos). In JMS 2.0 this has been ad­dressed. Need­less to say, the prob­a­bly of a per­fect match with our in­ter­pre­ta­tion was next to zero - so we had to make some changes.

To pre­serve com­pat­i­bil­i­ty your in­stances of AtomikosCon­nec­tionFac­to­ryBean now of­fer an ex­tra method setSes­sionCreationMode(int mode) which changes be­hav­iour as de­scribed be­low. The de­fault is val­ue 2 (JMS 2.0) so for com­pat­i­bil­i­ty with 5.0, try val­ue 1. For com­pat­i­bil­i­ty with pre-3.9 in­stal­la­tions, try val­ue 0.

Ses­sionCreationMode.JMS_2_0 (the de­fault as of re­lease 6.0), re­solv­ing to con­stant val­ue 2

ex­ist­ing JTA trans­ac­tion for thread	lo­calTrans­ac­tionMode	re­sult­ing ses­sion
true	ig­nored	XA ses­sion
false	false	XA ses­sion
false	true	non-XA ses­sion ac­cord­ing to ses­sionTrans­act­ed/ac­knowl­edgeMode pa­ra­me­ters

Ses­sionCreationMode.PRE_6_0 (op­tion­al, for back­ward com­pat­i­bil­i­ty) - re­solv­ing to con­stant val­ue 1

lo­calTrans­ac­tionMode	ses­sionTrans­act­edFlag	re­sult­ing ses­sion
false	ig­nored	XA ses­sion
true	ig­nored	non-XA ses­sion ac­cord­ing to ses­sionTrans­act­ed/ac­knowl­edgeMode pa­ra­me­ters

Ses­sionCreationMode.PRE_3_9 (op­tion­al, for back­ward com­pat­i­bil­i­ty and equiv­a­lent to ig­noreSes­sionTrans­act­edFlag = false) - re­solv­ing to con­stant val­ue 0

lo­calTrans­ac­tionMode	ses­sionTrans­act­edFlag	re­sult­ing ses­sion
false	true	XA ses­sion
oth­er	oth­er	non-XA ses­sion ac­cord­ing to ses­sionTrans­act­ed/ac­knowl­edgeMode pa­ra­me­ters

You can also find this in the javadoc of the AtomikosCon­nec­tionFac­to­ryBean.

Fea­ture20711

Sup­port for Trans­ac­tionSyn­chro­niza­tionRegistry

De­scrip­tion

We now of­fer an im­ple­men­ta­tion of Trans­ac­tionSyn­chro­niza­tionRegistry de­fined in the more re­cent JTA spec­i­fi­ca­tions.

Tech­ni­cal de­tails

You can use an in­stance of com.atom­ikos.icatch.jta.Trans­ac­tionSyn­chro­niza­tionRegistryImp con­tained in mod­ule trans­ac­tions-jta.jar.

Un­less you are a ven­dor of per­sis­tence providers, you prob­a­bly won't ever need this class so we'll keep the ex­pla­na­tion to a min­i­mum - since ven­dors of per­sis­tence providers al­ready know all there is to know.

Changes im­pact­ing client API

An ex­tra class avail­able in our dis­tri­b­u­tion, for you to use if you want to.

Fea­ture199530

Make the trans­ac­tion tem­plate thread-safe

De­scrip­tion

In­stances of com.atom­ikos.icatch.jta.tem­plate.Trans­ac­tionTem­plate are now tread-safe.

Tech­ni­cal de­tails

The first im­ple­men­ta­tions of our tem­plate were not in­tend­ed for thread­ed use cas­es. Based on cus­tomer feed­back, we have changed that - so you can now reuse the same in­stance in dif­fer­ent threads - just like Spring's tem­plate.

Changes im­pact­ing client API

In­stead of hav­ing to cre­ate mul­ti­ple tem­plate in­stances, you can now reuse the same in­stance in dif­fer­ent places of your code base. This should sim­pli­fy your con­fig­u­ra­tion and code base.

Fea­ture192016

Bet­ter sup­port for bor­rowCon­nec­tion time­outs in the pool

De­scrip­tion

We've im­proved the pool log­ic so that bor­row re­quests can bet­ter re­spect the time­out.

Tech­ni­cal de­tails

When a con­nec­tion is re­quest­ed and none is avail­able, new con­nec­tions would be cre­at­ed in the ap­pli­ca­tion's thread. In case of net­work is­sues, this would block the ap­pli­ca­tion's thread, pos­si­bly for much longer than the bor­rowCon­nec­tionTime­out set­ting would (and should) al­low. That's be­cause there is no easy way to in­ter­rupt a blocked IO re­quest.

We now im­proved this as fol­lows:

• There is a sep­a­rate back­ground thread that grows the pool when need­ed.
• The ap­pli­ca­tion's thread waits for this thread to grow the pool, but no longer than spec­i­fied by bor­rowCon­nec­tionTime­out.

Changes im­pact­ing client API

No real changes are need­ed, ex­cept that it should work bet­ter.

Fea­ture189885

Re­fac­tor shut­down: im­prove wait­ing for in-flight trans­ac­tions

De­scrip­tion

We have sim­pli­fied and im­proved the shut­down log­ic.

Tech­ni­cal de­tails

Shut­down used to wait for a time­out bound by the val­ue of com.atom­ikos.icatch.de­fault­_­max_wait­_­time_on_shut­down. Re­cov­ery it­self is al­ready bound by a dif­fer­ent pa­ra­me­ter: com.atom­ikos.icatch.de­fault­_­max_­time­out. The pre­vi­ous log­ic used to mix those two and the re­sults were not al­ways clear.

We have sim­pli­fied this to the fol­low­ing:

• Shut­down waits for all ac­tive trans­ac­tions to fin­ish in the JVM.
• Then it per­forms a re­cov­ery pass to clean up as much as pos­si­ble.
• If both pre­vi­ous steps worked fine then there are no pend­ing trans­ac­tions and the trans­ac­tion log files can be delet­ed.
• On the oth­er hand, if ei­ther step has is­sues then the trans­ac­tion log files have to be kept (we log a warn­ing for that).

Changes im­pact­ing client API

You no longer need com.atom­ikos.icatch.de­fault­_­max_wait­_­time_on_shut­down in your jta.prop­er­ties file. Be­ware that shut­down du­ra­tion is bound by the val­ue of com.atom­ikos.icatch.de­fault­_­max_­time­out - un­less you use the "forceShut­down" op­tion.

Fea­ture182107

Re­move user / pass­word prop­er­ties from Mes­sageDrivenCon­tain­er

De­scrip­tion

The user and pass­word prop­er­ties have been re­moved from com.atom­ikos.jms.ex­tra.Mes­sageDrivenCon­tain­er be­cause they were nev­er used any­way.

Tech­ni­cal de­tails

In­stances of this class del­e­gate to com.atom­ikos.jms.AtomikosCon­nec­tionFac­to­ryBean to cre­ate con­nec­tions. The lat­ter is also con­fig­ured with a user and pass­word, and those are the val­ues that are ac­tu­al­ly be­ing used.

As a re­sult, keep­ing two un­used prop­er­ties in the com.atom­ikos.jms.ex­tra.Mes­sageDrivenCon­tain­er class was con­fus­ing - so we have re­moved those.

Changes im­pact­ing client API

You need to re­move any ref­er­ences to these prop­er­ties from your con­fig­u­ra­tion.

Fea­ture199528

Drop reap­ing func­tion­al­i­ty from the pools

De­scrip­tion

We've re­moved the reap­ing func­tion­al­i­ty from the pools.

Tech­ni­cal de­tails

Reap­ing was when our pools would take away con­nec­tions that were be­ing held onto for too long.

His­tor­i­cal­ly, reap­ing func­tion­al­i­ty has caused more prob­lems / con­fu­sion than it solved. More­over, it was in­tend­ed to fix ap­pli­ca­tion-lev­el con­nec­tion leaks, mean­ing bugs in the ap­pli­ca­tion (as op­posed to bugs in our code base). We felt that be­came a source of need­less com­plex­i­ty.

We be­lieve that the cor­rect way of fix­ing ap­pli­ca­tion-lev­el con­nec­tion leaks is by fix­ing the ap­pli­ca­tion, rather than abrupt­ly reap­ing con­nec­tions away from that ap­pli­ca­tion. So our 6.0 re­lease seemed a good time to re­move that fea­ture.

Changes im­pact­ing client API

Re­move any ref­er­ences to reapTime­out from your con­fig­u­ra­tion.

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.

Bug200555

Also close Cal­lable- and Pre­paredS­tate­ments when JDBC con­nec­tion is closed

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

De­scrip­tion

Now you can close a JDBC con­nec­tion and also have the Cal­lable- and Pre­paredS­tate­ments closed au­to­mat­i­cal­ly.

Tech­ni­cal de­tails

When a JDBC con­nec­tion is closed by the ap­pli­ca­tion (re­turned to the pool) then the JDBC spec­i­fi­ca­tion re­quires all pend­ing state­ments to be closed as well.

We sup­port­ed this, but ap­par­ent­ly this was not done for all state­ment types. We fixed this now.

This is­sue is marked as sever­i­ty 4 (de­vel­op­ment use) be­cause we had no real bug re­ports from any cus­tomers. It was some­thing we no­ticed dur­ing a code re­view.

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.

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.

Bug200925

Im­prove han­dling of null xare­source

Sever­i­ty:	3
Af­fect­ed ver­sion(s):	3.9.x, 4.0.x, 5.0.x

De­scrip­tion

We've re­fined how we deal with lost XA con­nec­tions dur­ing the com­mit phase.

Tech­ni­cal de­tails

Some con­nec­tion is­sues would lead to need­less heuris­tic ex­cep­tions dur­ing com­mit, in par­tic­u­lar when the com­mit was 1-phase (where fail­ure to reach the back­end re­sults in re­source-in­ter­nal roll­back any­way).We have now re­fined this so there are no need­less heuris­tic ex­cep­tions any more in these cas­es. At the same time, we have also tried to min­imise the num­ber of cas­es where such con­nec­tion is­sues re­main.

Changes im­pact­ing client API

None.

Bug201164

Avoid Con­cur­ren­tMod­i­fi­ca­tionEx­cep­tion dur­ing trace log­ging in the pool

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

De­scrip­tion

You can now use our pools with TRACE log­ging and get less ex­cep­tions.

Tech­ni­cal de­tails

The is­sue de­tails are de­scribed in this GitHub is­sue.

Changes im­pact­ing client API

None.

Is­sue201646

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

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

De­scrip­tion

Un­like Spring Boot 3 sup­port, we did not yet add the JMS and JTA de­pen­den­cies in the Spring Boot 2 starter.

Tech­ni­cal de­tails

We still have to add the JMS and JTA de­pen­den­cies in the Spring Boot 2 starter. This is need­ed be­cause of the re­moval of tran­si­tive de­pen­den­cies. Un­til then, you will have to add them your­self.

Free Down­load

Bug181871

Avoid that Con­nec­tionPoolWithCon­cur­ren­tVal­i­da­tion grows be­yond maxPoolSize

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

De­scrip­tion

We've port­ed a fix from our com­mer­cial re­lease that pre­vents the pool from ex­ceed­ing its maxPoolSize.

Tech­ni­cal de­tails

The con­cur­rent pool does not en­force syn­chro­niza­tion so when it:

1. checks if the pool can grow and then
2. ac­tu­al­ly grows it

... a dif­fer­ent thread may have done the same and the pool grows too much.

So­lu­tion: we've made growPool (with ex­ist­ing syn­chro­nized block) check maxSize again, and don't grow if al­ready at the max­i­mum.

Changes im­pact­ing client API

None.