Fea­ture172711

Sup­port for net­workTime­out on the JDBC con­nec­tions

You can now con­fig­ure a net­workTime­out pa­ra­me­ter for the pool.

Tech­ni­cal de­tails

Net­work is­sues are a re­cur­ring prob­lem for con­nec­tion pools: a pool at­tempts to keep con­nec­tions open, where­as in­ter­me­di­aries on the net­work tend to close them (silent­ly). In ad­di­tion, backed servers go­ing down can also in­val­i­date the pool's con­nec­tions.

Th­ese con­di­tions can eas­i­ly lead to long block times on the pool and its con­nec­tions and the ap­pli­ca­tion thus be­comes un­re­spon­sive. By set­ting the new net­workTime­out prop­er­ty on our data­source class­es you can lim­it the time that ap­pli­ca­tions can block on the net­work.

This new fea­ture only works if the un­der­ly­ing dri­ver sup­ports it (leave the prop­er­ty un­set if not). Also, any time­out val­ue you con­fig­ure must be high­er than the typ­i­cal du­ra­tion of your SQL op­er­a­tions, so it must also be high­er than the trans­ac­tion time­out.

Changes im­pact­ing client API

FREE TEXT / OPTIONAL

Bug194432

Log warn­ing on er­rors dur­ing pre­pare

Sever­i­ty:	3
Af­fect­ed ver­sion(s):	5.0.107

De­scrip­tion

We now log warn­ings for er­rors dur­ing the pre­pare phase.

Tech­ni­cal de­tails

When an er­ror hap­pens dur­ing pre­pare then we used to log de­bug in­for­ma­tion. Con­se­quent­ly, some use­ful in­for­ma­tion was hard to find, in par­tic­u­lar fail­ures due to de­ferred con­straint vi­o­la­tions. We now log as warn­ings in­stead.

Changes im­pact­ing client API

None.

Bug194408

Fixed javadoc is­sue dur­ing re­lease up­load

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

De­scrip­tion

You can now (again) ac­cess the javadoc in your IDE.

Tech­ni­cal de­tails

We en­coun­tered a re­lease prob­lem in the 5.0.107 re­lease for which we had to dis­able the javadoc plu­g­in. This meant that most of that re­lease went un­doc­u­ment­ed. We have now fixed this.

Changes im­pact­ing client API

None, ex­cept that the doc­u­men­ta­tion is now in­clud­ed.

Fea­ture188756

Spring Boot Starter

Con­tributed by the Spring (Boot) team, we are hap­py to an­nounce our new Spring Boot starter mod­ule! You can now use our re­leas­es 5.0 with the lat­est re­leas­es from Spring Boot.

Tech­ni­cal de­tails

Our re­leas­es 5.0 were not com­pat­i­ble with the Spring Boot starter code as it was im­ple­ment­ed by the Spring Boot team (and in­clud­ed in the "na­tive" starters for Spring Boot).

So based on a gen­er­ous con­tri­bu­tion from the Spring Boot team and Piv­otal, we now have our own starter mod­ule for you to use: just add trans­ac­tions-spring-boot-starter to your pom and off you go.

See https://www.atom­ikos.com/Doc­u­men­ta­tion/SpringBootIn­te­gra­tion for ad­di­tion­al de­tails.

Changes im­pact­ing client API

No oth­er changes: we have pre­served the Spring Boot con­fig­u­ra­tion op­tions.

Fea­ture194218

Restruc­ture mod­ule trans­ac­tions-spring­boot2

This mod­ule has been re­named and part of the code in­side has been moved.

Tech­ni­cal de­tails

With the new Spring Boot starter mod­ule (see 188756 above) the name of mod­ule trans­ac­tions-spring­boot2 seemed awk­ward and over­lap­ping with the Spring Boot starter code. So we have de­cid­ed to:

• Move the meta­da­ta class­es from pack­age com.atom­ikos.spring­boot.au­to­con­fig­ure.jdbc.meta­da­ta from mod­ule trans­ac­tions-spring­boot2 into the new mod­ule trans­ac­tions-spring-boot (this mod­ule was added per 188756 above).
• Re­name the mod­ule trans­ac­tions-spring­boot2 to trans­ac­tions-spring-boot-log­cloud to re­flect the true in­ten­tion of the re­main­ing code in this mod­ule.

Changes im­pact­ing client API

This is a break­ing change if you were us­ing trans­ac­tions-spring­boot2 al­ready.

Bug190245

Com­pat­i­bil­i­ty with JDK 11

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

De­scrip­tion

You can now run our ex­am­ple pro­grams with JDK 11.

Tech­ni­cal de­tails

Our ex­am­ples did not build well with JDK 11 due to the new Java mod­ule sys­tem in­tro­duced, and the fact that some pack­ages are no longer vis­i­ble (by de­fault) in the JDK. This has now been fixed.

Changes im­pact­ing client API

None: there is a sep­a­rate maven build pro­file that ac­ti­vates it­self when a re­cent JDK is found, and tunes the mod­ules ac­cord­ing­ly.

Is­sue194408

Javadoc is­sue dur­ing re­lease up­load

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

De­scrip­tion

This re­lease does not in­clude the full javadoc.

Tech­ni­cal de­tails

The javadoc gen­er­a­tion failed dur­ing the up­load of the re­lease due to in­com­pat­i­bil­i­ty is­sues with the Spring Boot starter's in­te­gra­tion tests. To avoid ad­di­tion­al de­lays, we have for now up­loaded this re­lease with­out most of the javadoc.

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.