Big news: our new 3.7.0M2 re­leas­es are out for Ex­tremeTrans­ac­tions and Trans­ac­tion­sEssen­tials!

If you look at the re­lease notes then you will see that there are not that many new fea­tures (be­sides bug fix­es and some im­por­tant per­for­mance tun­ing). So what makes these new re­leas­es big news then? It's our new re­lease process and build in­fra­struc­ture that made them pos­si­ble.

That's right: we have a new build process. We are now of­fi­cial­ly us­ing maven and mer­cu­r­ial for our builds, in­stead of ant and svn. Also, we have tuned our repos­i­to­ry ar­chi­tec­ture to bet­ter match our busi­ness mod­el: we are now tuned to­wards more fre­quent re­leas­es of Ex­tremeTrans­ac­tions and op­ti­mized even more for our sup­port busi­ness.

So we hope you en­joy the new re­leas­es as much as we do! Be­ware though: they are mile­stone builds, mean­ing they are bound to have mi­nor is­sues still. This is most­ly due to ini­tial im­per­fec­tions in our new build process. After all, it is a new way of work­ing for all of us!

The Atomikos con­nec­tion pool­ing mech­a­nism in­val­i­dates con­nec­tions when there are any er­rors - just to be sure that lat­er trans­ac­tions are not cor­rupt­ed by pri­or er­rors on the con­nec­tion stream to the back-end. Also, some­times con­nec­tions sim­ply time out in the back-end, and are closed with­out warn­ing. So it may hap­pen that you have some 'er­ro­neous' con­nec­tions in the pool at any giv­en time, and you will only find out the next time you try to use one of these con­nec­tions (i.e., in your ap­pli­ca­tion log­ic you will see ex­cep­tions re­lat­ed to this).

To avoid this (and have the pool proac­tive­ly val­i­date con­nec­tions for you) just set a testQuery on the AtomikosDataSourceBean in­stance. The idea is that you sup­ply a snip­pet of SQL code that can be used by the pool to test if the con­nec­tion is still valid. If not, it will be re­placed au­to­mat­i­cal­ly - and you should nev­er get any er­ro­neous con­nec­tion out of the pool.

The fact that the testQuery is op­tion­al has been con­fus­ing to some users. Con­se­quent­ly, we've been asked to make it re­quired or de­fault to some­thing mean­ing­ful. We've se­ri­ous­ly thought about this, but there are a few prob­lems here:

• Mak­ing it re­quired means break­ing a lot of ex­ist­ing, work­ing con­fig­u­ra­tions when they up­grade to our newest re­lease. That is be­cause these ex­ist­ing con­fig­u­ra­tions usu­al­ly do not in­clude any testQuery set­tings and the new re­lease would fail to read the con­fig­u­ra­tion and ini­tial­ize cor­rect­ly - there­by break­ing back­wards com­pat­i­bil­i­ty. We did not want to do this.
• Pro­vid­ing a rea­son­able de­fault is equal­ly dif­fi­cult, if not even hard­er: it turns out that there is no known SQL state­ment that will work for all DBMS. So our de­fault testQuery - whichev­er we choose - would al­ways fail on some sys­tems. We did not want to do this ei­ther.

So what did we do to im­prove this? After some in­put from our LinkedIn group we now have a se­ri­ous warn­ing mes­sage in the logs when­ev­er you don't set the testQuery.

Note: this will be avail­able in our very next re­lease - due be­gin­ning of Oc­to­ber.

Maybe you have no­ticed: we have re­cent­ly changed our de­vel­op­er ac­cess for­mu­la - based on cus­tomer feed­back. Where­as the 'old' for­mu­la used to be tick­et-based and ex­pired af­ter 1 month, the new de­vel­op­er ac­cess is as fol­lows:

• There is no lim­it on the num­ber of is­sues
• Ex­piry is af­ter ei­ther 3 or 6 months (your choice) - which gives you plen­ty of time to ex­per­i­ment
• There is, how­ev­er, a lim­it of 1 named con­tact at the side of the cus­tomer

Again, this is based on in­put we got from sev­er­al cus­tomers and prospects. Thanks for your feed­back!

PS yes, the old for­mu­la has been dis­con­tin­ued: we too ex­pe­ri­enced prob­lems with the is­sue lim­it...

UPDATE 2018: we now only have sub­scrip­tions - where de­vel­op­er ac­cess is a in­clud­ed in the of­fer­ing...

When im­ple­ment­ing a ser­vice-ori­ent­ed ar­chi­tec­ture (SOA), there is al­ways the choice be­tween com­po­nents (in­clud­ed mod­ules of reusable func­tion­al­i­ty) ver­sus ser­vices (de­ployed once, reused by calls over the net­work).

How do you know which one to choose? There is a lot of things to con­sid­er, but these will give you a head-start:

• if there is a need for dif­fer­ent con­fig­u­ra­tion pa­ra­me­ters per con­sumer, fa­vor a com­po­nent
• if per­for­mance of re­mote net­work calls is prob­lem­at­ic, fa­vor a com­po­nent
• if de­ploy-once is cru­cial, fa­vor a ser­vice
• if you have no con­trol over the de­ploy­ment pa­ra­me­ters, fa­vor a ser­vice (e.g., if the provider is a third par­ty)
• to dy­nam­i­cal­ly switch be­tween both, choose ser­vice com­po­nent ar­chi­tec­ture (SCA)

Also, keep in mind that com­po­nents re­quire set­ting up the re­quired in­fra­struc­ture (data­base schema, queues, etc) for each de­ploy­ment.

Prob­a­bly most read­ers of this blog post will know about com­po­nents, be­cause you prob­a­bly use Trans­ac­tion­sEssen­tials as a com­po­nent

In an at­tempt to 'in­crease per­for­mance', many peo­ple will try to hack around in JMS - there­by falling into the idem­po­tent re­ceiv­er trap by check­ing for du­pli­cate mes­sage re­ceipt. The con­se­quence: scal­a­bil­i­ty ac­tu­al­ly de­grades!

For­tu­nate­ly, the best way to en­joy re­li­able mes­sag­ing is also the sim­plest one, and it scales lin­ear­ly.