Trans­ac­tion­sEssen­tials 5.0

Re­lease notes for the 5.0 re­lease

Re­mot­ing for trans­ac­tions across mi­croser­vices, new im­proved re­cov­ery, sim­pli­fied de­sign and bet­ter JDBC sup­port.

Up­grad­ing from 4.0

Up­grad­ing should be easy, and in case you have is­sues then do the fol­low­ing to get back­ward com­pat­i­bil­i­ty:

• Set lo­calTrans­ac­tionMode=true on your JDBC data­source(s)
• In jta.prop­er­ties, set com.atom­ikos.icatch.throw_on_heuris­tic=true

IMPORTANT: since the log file for­mat has changed, make sure to do a clean shut­down first so you can safe­ly re­move the ex­ist­ing trans­ac­tion logs.

Re­mot­ing sup­port for mi­croser­vices

Ever heard of ACID trans­ac­tions be­ing an anti-pat­tern? Most­ly this is be­cause peo­ple don't know how to do it. This has now changed!

Check out ex­am­ples-jta-rest-jaxrs to see how easy it is to com­mit or roll­back across mul­ti­ple ser­vices.

Sim­ple Trans­ac­tionTem­plate

Maybe you use Spring, maybe you don't. Either way, you can now use our new com.atom­ikos.icatch.jta.tem­plate.Trans­ac­tionTem­plate to de­mar­cate trans­ac­tions with the known se­man­tics (REQUIRED, REQUIRES_NEW, MANDATORY, NEVER, SUPPORTS, NOT_SUPPORTED and NESTED). Lamb­da's are sup­port­ed, too.

No throw­ing of heuris­tic ex­cep­tions

We no longer throw on heuris­tic ex­cep­tions - be­cause heuris­tics are an op­er­a­tions is­sue, not a de­vel­op­er is­sue. How­ev­er, if your code de­pends on heuris­tics then you can switch on the old be­hav­iour in jta.prop­er­ties like this:

com.atomikos.icatch.throw_on_heuristic=true

New and sim­pli­fied re­cov­ery

We've made re­cov­ery even sim­pler, so it works bet­ter and faster - even in the cloud: your ap­pli­ca­tion's trans­ac­tion pro­cess­ing now mere­ly in­serts log records, and all oth­er pro­cess­ing and cleanup is done in the back­ground (by the re­cov­ery sub­sys­tem). This achieves the ul­ti­mate and com­plete sep­a­ra­tion of con­cerns be­tween OLTP log­ic and re­cov­ery log­ic. The logs are also more com­pact be­cause we no longer store in­di­vid­ual XIDs.

Au­to­mat­ic archiv­ing of heuris­tic prob­lems

Heuris­tic prob­lem cas­es are now most­ly archived au­to­mat­i­cal­ly so they will no longer "pol­lute" the log files. Your ap­pli­ca­tion can cap­ture de­tails with our event API - so you can log what­ev­er you need to deal with such prob­lems.

The LogAd­min­is­tra­tor in­ter­face had been re­moved from our API be­cause it be­came ob­so­lete now that we deal with heuris­tics au­to­mat­i­cal­ly.

Fil­ter out "du­pli­cate" re­sources for re­cov­ery

With the 4.0 re­cov­ery, mul­ti­ple con­nec­tion fac­to­ries or data­source to the same back­end would lead to many re­cov­ery calls. Now we fil­ter out du­pli­cates - so each backed is only re­cov­ered once dur­ing each re­cov­ery scan.

Easy proxy cre­ation

We've added sup­port for easy and el­e­gant dy­nam­ic proxy cre­ation. This means that we can have bet­ter prox­ies (typ­i­cal­ly need­ed for JTA en­list/delist). Our JDBC and JMS mod­ules have been refac­tored to lever­age this new de­sign.

API sim­pli­fi­ca­tion

We've sim­pli­fied our (in­ter­nal) API based on in­sights we've col­lect­ed over the years. Most no­tably, our API no longer re­quires Se­ri­al­iz­able sup­port and the trans­ac­tion im­port/ex­port mech­a­nism has also been cleaned up to al­low for el­e­gant HTTP / mi­croser­vice trans­ac­tions.

Im­proved JDBC Non-XA sup­port

The class­es for the non-XA data­source have been im­proved for more safe­ty and flex­i­bil­i­ty:

• Sub­trans­ac­tions are now sup­port­ed
• Mul­ti­ple read-only in­stances can be used in the same trans­ac­tion
• Non-read-only in­stances will fail if used in two-phase com­mit

Here are some rel­e­vant GitHub is­sues:

• https://github.com/atom­ikos/trans­ac­tions-es­sen­tials/is­sues/83
• https://github.com/atom­ikos/trans­ac­tions-es­sen­tials/is­sues/85

Also, the class AtomikosNonXADataSourceBean has now been moved into pack­age com.atom­ikos.jdbc (along­side our AtomikosDataSourceBean).

Safer JDBC de­sign

We used to al­low a mix of lo­cal trans­ac­tions and JTA trans­ac­tions (de­pend­ing on whether a JTA trans­ac­tion ex­ist­ed or not). As of this re­lease, only JTA trans­ac­tions are al­lowed for JDBC - un­less ex­plic­it­ly over­rid­den by set­ting "lo­calTrans­ac­tionMode=true" on any of our data­sources.

JDBC state­ment house­keep­ing

We no longer keep JDBC state­ments af­ter they are closed, which means less mem­o­ry con­sump­tion.

Jm­sSen­derTem­plateCall­back is a func­tion­al in­ter­face

For the lamb­da lovers: you can now do these with the Jm­sSen­derTem­plateCall­back.

Ex­am­ple with Hiber­nate 5

We've in­clud­ed a work­ing sam­ple with hi­ber­nate 5

Ex­am­ple with Spring 5.1

We've up­grad­ed the Spring ex­am­ple to use a re­cent ver­sion of Spring.

Re­moved JUL log­ger from ex­am­ples

Some peo­ple thought we had a JUL log­ger de­pen­den­cy in the ex­am­ples. This has now been re­moved.

Free Down­load