Ex­tremeTrans­ac­tions 6.0.110

Re­lease notes for 6.0.110

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.

About Sever­i­ty

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