Did you ever won­der why sud­den­ly you have to un­der­stand com­plex pat­terns like Sa­gas or even­tu­al con­sis­ten­cy?

Here is the an­swer: be­cause with mi­croser­vices and cloud, peo­ple think they no longer have ac­cess to the tech­nol­o­gy that has been around for decades: a dis­trib­uted trans­ac­tion man­ag­er. (We know, even many ex­perts be­lieve this).

Typ­i­cal­ly part of every ap­pli­ca­tion serv­er, such a trans­ac­tion man­ag­er takes care of roll­back across re­sources (so you don’t need Sa­gas) and re­li­able mes­sage de­liv­ery (so even­tu­al con­sis­ten­cy is au­to­mat­ic).

But ap­pli­ca­tion servers are dis­ap­pear­ing be­cause they are nei­ther ag­ile, nor cloud-friend­ly nor mi­croser­vice-friend­ly. So what can one do?

En­ter Atomikos: we have re­designed the essence of the ap­pli­ca­tion serv­er to be light­weight and em­bed­d­a­ble, so you can get start­ed with mi­croser­vices and cloud with­out need­ing com­plex pat­terns like Sa­gas or even­tu­al con­sis­ten­cy. Thanks to our con­nec­tion pools and trans­ac­tion man­ag­er, you get all the re­li­a­bil­i­ty of an ap­pli­ca­tion serv­er - but em­bed­ded in your mi­croser­vice ap­pli­ca­tions and de­ployed to your cloud plat­form.

From now on, your mi­croser­vice trans­ac­tions are as easy as adding the @Trans­ac­tion­al an­no­ta­tion on your ser­vices. Ex­act­ly-once mes­sag­ing is su­per easy be­cause a trans­ac­tion man­ag­er au­to­mat­i­cal­ly avoids mes­sage loss and/or du­pli­cate mes­sage pro­cess­ing.

We of­fer out-of-the-box in­te­gra­tion with the most pop­u­lar Java run­times like Spring (Boot) and Tom­cat.

Did we men­tion that we have fine-tuned per­for­mance? With our smart batch­ing tech­nol­o­gy, your pro­cess­ing can even be faster than be­fore. And it’s elas­tic too, for dy­nam­ic scal­ing.

Join nu­mer­ous banks and in­sur­ance com­pa­nies world­wide and find out why Gart­ner has named us a cool ven­dor.

Want to learn more? Down­load our FREE ebook "Mi­croser­vice Trans­ac­tion Pat­terns":

Send Me The Ebook!

I have read and ac­cept the pri­va­cy pol­i­cy.

Fea­ture193912

Add sup­port for Hazel­cast 4

You can now use Hazel­cast 4 with our JTA/XA trans­ac­tions, via an ad­di­tion­al mod­ule "trans­ac­tions-hazel­cast4". This was re­quired due to break­ing API changes that were in­tro­duced in Hazel­cast 4.

Tech­ni­cal de­tails

When us­ing the pri­or Hazel­cast in­te­gra­tion (made for Hazel­cast 3, not 4) you would get the fol­low­ing ex­cep­tion when try­ing to con­fig­ure a JTA/XA en­abled Hazel­castIn­stance:

java.lang.UnsupportedOperationException: Client config object only supports adding new data structure configurations
at com.hazelcast.client.impl.clientside.ClientDynamicClusterConfig.getLicenseKey(ClientDynamicClusterConfig.java:897)
at com.hazelcast.config.ConfigXmlGenerator.generate(ConfigXmlGenerator.java:129)
at com.atomikos.hazelcast.HazelcastTransactionalResource.<init>(HazelcastTransactionalResource.java:23)
at com.atomikos.hazelcast.AtomikosHazelcastInstance.<init>(AtomikosHazelcastInstance.java:31)
at com.atomikos.hazelcast.AtomikosHazelcastInstanceFactory.createAtomikosInstance(AtomikosHazelcastInstanceFactory.java:17)
at ...

Changes im­pact­ing client API

If you are us­ing the rec­om­mend­ed con­fig­u­ra­tion method then noth­ing changes, al­though we did sim­pli­fy the event com.atom­ikos.hazel­cast4.Hazel­castDe­tect­edEvent to con­tain only the uniqueRe­sourceName. The rest of the in­for­ma­tion (i.e., pass­word and XML con­fig­u­ra­tion in­for­ma­tion) has been re­moved from the event.

Bug190537

Al­low Ses­sionHan­dleS­tate reuse af­ter clos­ing a pooled con­nec­tion with re­cy­cleAc­tiveCon­nec­tion­sInTrans­ac­tion=true

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

De­scrip­tion

When set­ting re­cy­cleAc­tiveCon­nec­tion­sInTrans­ac­tion=true, you can now reuse con­nec­tions more flex­i­bly.

Tech­ni­cal de­tails

Con­sid­er the fol­low­ing use case with re­cy­cleAc­tiveCon­nec­tion­sInTrans­ac­tion en­abled:

Method foo():

1. Open con­nec­tion c1
2. Do SQL with c1
3. Call method bar()
4. Do more SQLs with con­nec­tion c1
5. Close c1

Method bar():

1. Open con­nec­tion c2
2. Do SQL with c2
3. Close c2

With re­cy­cleAc­tiveCon­nec­tion­sInTrans­ac­tion=true, c1 will be the same con­nec­tion in­stance as c2.

So af­ter method bar() clos­es c2, c1 will also be closed and this caused er­rors like these in step 4 of method foo():

The underlying XA session is closed
                at com.atomikos.jdbc.internal.AtomikosSQLException.throwAtomikosSQLException(AtomikosSQLException.java:29)
                at com.atomikos.jdbc.internal.AtomikosJdbcConnectionProxy.enlist(AtomikosJdbcConnectionProxy.java:108)
                at com.atomikos.jdbc.internal.AtomikosJdbcConnectionProxy.updateTransactionContext(AtomikosJdbcConnectionProxy.java:61)
                at com.atomikos.jdbc.internal.AbstractJdbcConnectionProxy.prepareStatement(AbstractJdbcConnectionProxy.java:64)
                at sun.reflect.GeneratedMethodAccessor228.invoke(Unknown Source)
                at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
                at java.lang.reflect.Method.invoke(Method.java:498)
                at com.atomikos.util.DynamicProxySupport.callProxiedMethod(DynamicProxySupport.java:162)
                at com.atomikos.util.DynamicProxySupport.invoke(DynamicProxySupport.java:116)
                at com.sun.proxy.$Proxy801.prepareStatement(Unknown Source)

Changes im­pact­ing client API

None.

Fea­ture190375

Al­low re­cy­cling of ac­tive con­nec­tions with­in the same trans­ac­tion

You can now al­low re­cy­cling of ac­tive JDBC/XA pooled con­nec­tions with­in the same trans­ac­tion, be­fore they are "closed" by the ap­pli­ca­tion. This means that cer­tain dead­lock sce­nar­ios can be avoid­ed.

Tech­ni­cal de­tails

Imag­ine the fol­low­ing use case:

1. start a JTA trans­ac­tion
2. get a JDBC/XA con­nec­tion (c1) from the pool via getCon­nec­tion()
3. do some SQL on c1
4. get a sec­ond JDBC/XA con­nec­tion (c2) from the pool via getCon­nec­tion()

Be­fore this fea­ture, step 4 would re­turn a dif­fer­ent phys­i­cal con­nec­tion from the pool. This would trig­ger a new XA branch, with un­spec­i­fied iso­la­tion (lock­ing) be­hav­iour with re­spect to any up­dates per­formed via the con­nec­tion in step 2. This could even cause dead­locks.

There­fore, peo­ple have asked us to al­low for step 4 to reuse the same con­nec­tion, c1. You can now en­able this new be­hav­iour by call­ing setRe­cy­cleAc­tiveCon­nec­tion­sInTrans­ac­tion(true) on the AtomikosDataSourceBean.

Changes im­pact­ing client API

A new, op­tion­al set­ter on our data­source. The de­fault is false for back­ward com­pat­i­bil­i­ty.

Read this for our ex­pe­ri­ence with run­ning on JDK 11...