Let's face it: most "re­silient" mi­croser­vice de­signs are still los­ing data.

It is not that de­vel­op­ers aren't try­ing. They are. You see it in the end­less retry log­ic, idem­po­ten­cy to­kens, and cir­cuit break­ers piled into every ser­vice. You see it in all the apolo­getic blog posts ex­plain­ing why 'even­tu­al con­sis­ten­cy' is a fea­ture, not a bug.

But here is the un­com­fort­able truth: these pat­terns are treat­ing the symp­toms, not the dis­ease. If you've ever faced du­pli­cate mes­sages, in­con­sis­tent state across ser­vices, or the dread­ed par­tial fail­ure in a dis­trib­uted sys­tem, then you have seen it up close.

The root cause? Miss­ing trans­ac­tion­al­i­ty.

In the world of mi­croser­vices and light-weight in­fra­struc­ture, a lot of teams think they should roll their own even­tu­al con­sis­ten­cy "pat­terns" - let's call this "cus­tom even­tu­al con­sis­ten­cy". So they end up cod­ing a lot that needs to be test­ed for bor­der-case sce­nar­ios. Even if this is done, the re­sult rarely cov­ers all cas­es, and not every­body wants to main­tain this kind of code.

If you are build­ing mi­croser­vices, you have prob­a­bly heard of the Saga pat­tern. Maybe you are even us­ing it. After all, it is the de­fault an­swer you will find on Stack Over­flow and in most con­fer­ence talks when peo­ple ask: How do I man­age dis­trib­uted trans­ac­tions?

Syn­chro­nous mi­croser­vices look great on pa­per.

They are easy to read, easy to de­bug, and they map per­fect­ly to how we think: “I send a re­quest, I get a re­ply.” No sur­pris­es, right?

Ex­cept when things go wrong. Which in dis­trib­uted sys­tems is most of the time.

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.