Atomikos Of­fers 3rd Gen­er­a­tion TP Mon­i­tors

Why our tech­nol­o­gy is so dif­fer­ent from what you know...

This post on In­foQ was made by Ar­ju­na, one of our (ex) com­peti­tors af­ter JBoss (and then Red Hat) bought their trans­ac­tion tech­nol­o­gy.

More in­ter­est­ing than the re­ferred pa­per are the com­ments, which I would like to dis­cuss here. Most posts seem to rule out trans­ac­tions as some­thing that doesn't scale. None of these com­ments I agree with.

The main com­plaints ut­tered seem to fall into these cat­e­gories:

1. Trans­ac­tion man­agers are sup­pos­ed­ly cen­tral­ized.
2. Trans­ac­tion man­agers are ac­cused of over­head for two-phase com­mit and syn­chro­niza­tion.

I will now show that both these state­ments are a mis­con­cep­tion, claim­ing that the 3rd gen­er­a­tion trans­ac­tion mon­i­tor al­ready ex­ists. More­over, I will show that 3rd gen­er­a­tion trans­ac­tion man­agers are bet­ter than (or at least as good as) the al­ter­na­tives - when used cor­rect­ly.

The prod­uct I am talk­ing about is Atomikos Ex­tremeTrans­ac­tions, in­clud­ing its JTA/XA open source edi­tion named Trans­ac­tion­sEssen­tials. Let me now out­line why none of the above ob­jec­tions are ac­tu­al­ly ac­cu­rate:

1. Atomikos Ex­tremeTrans­ac­tions is a peer-to-peer sys­tem for trans­ac­tions. When­ev­er two or more process­es are in­volved in the same trans­ac­tion, the trans­ac­tion man­ag­er com­po­nent (li­brary) in each process will col­lab­o­rate with its peer coun­ter­part in the oth­er process. This is how it is done. Con­se­quent­ly, there is no cen­tral­ized com­po­nent nor bot­tle­neck. Our stud­ies have shown that this gives you lin­ear (i.e., per­fect) scal­a­bil­i­ty. This in­val­i­dates the first crit­i­cism above.
2. While two-phase com­mit does in­cur some syn­chro­niza­tion, the same is true for any oth­er so­lu­tion (as­sum­ing that you want to push op­er­a­tions to one or more back­ends). A sim­ple ex­am­ple to il­lus­trate my point: many peo­ple think that queu­ing is a way to avoid the need for trans­ac­tions (and two-phase com­mit). Is it? Hard­ly: even if we ne­glect the re­sult­ing risk in mes­sage loss then you have to re­al­ize that most queue­ing sys­tems use two-phase com­mit in­ter­nal­ly any­way. This in­val­i­dates the sec­ond crit­i­cism above.
3. The of­ten-heard crit­i­cism that trans­ac­tions may block your data is not fair ei­ther.
   There is some in­ter­est­ing the­o­ret­i­cal work done by Nan­cy Lynch (MIT) et al - I be­lieve it is this one. Ba­si­cal­ly, this is math­e­mat­ics that proves that you can­not have a non-block­ing (read: per­fect) so­lu­tion for dis­trib­uted agree­ment in re­al­is­tic sce­nar­ios.
   In prac­tice, this means that a queued op­er­a­tion may not make it if the con­nec­tion to the re­ceiv­er is down too long. So your sys­tem is 'blocked' in the queue, even though you don't use trans­ac­tions. This is the equiv­a­lent of the per­ceived 'block­ing' but now placed in a non-trans­ac­tion­al sce­nario.
4. Again on the per­ceived syn­chro­niza­tion over­head: if you don't keep track of "what" you have done and "where" (by syn­chro­niz­ing) then you end up with an er­ror-prone process. This is es­pe­cial­ly true for many crit­i­cal ap­pli­ca­tions that con­sume mes­sages and in­sert the re­sults in a data­base. If you don't use trans­ac­tions then you will find your­self im­ple­ment­ing du­pli­cate mes­sage de­tec­tion and/or du­pli­cate elim­i­na­tion, none of which are safe with­out the prop­er com­mit or­der­ing. Ba­si­cal­ly, you are im­ple­ment­ing a trans­ac­tion man­ag­er your­self (yuk!).

Am I say­ing that trans­ac­tions and two-phase com­mit don't block? Not ex­act­ly - es­pe­cial­ly if you use XA then things can block. How­ev­er, Atomikos avoids this in two ways:

• Very strong heuris­tic sup­port: uni­lat­er­al de­ci­sion are en­cour­aged both in the back­end and in the Atomikos trans­ac­tion man­ag­er. If a trans­ac­tion takes too long, it is ter­mi­nat­ed any­how. Where clas­si­cal sce­nar­ios would block, Atomikos en­forces a uni­lat­er­al ter­mi­na­tion by ei­ther par­ty. The re­sult­ing anom­aly is re­flect­ed in the trans­ac­tion logs, so the trans­ac­tion man­ag­er can track prob­lem cas­es (in­stead of let­ting you chase dif­fer­ent sys­tems to find out what hap­pened - the al­ter­na­tive with­out trans­ac­tions). Iron­i­cal­ly, we have seen more blocks caused by non-XA trans­ac­tions: if your data­base does not sup­port an in­ter­nal time­out mech­a­nism for non-XA (which seems to be so in the most com­mon­ly used DBMS) then it will be non-XA trans­ac­tions that cause the block­ing!. I can go on for hours about this - but that is an­oth­er post.
• Atomikos also of­fers lo­cal trans­ac­tions with com­pen­sa­tion in­stead of roll­back: you can use our TCC (Try-Can­cel/Con­firm) API to han­dle over­all roll­back. This al­lows you to use non-XA, lo­cal trans­ac­tions. It nev­er blocks your ap­pli­ca­tion, ever! TCC is sim­i­lar to WS-BA, only bet­ter be­cause we have been work­ing on it for much longer than any­body else in the world.

Sum­ming up then: do I rec­om­mend two-phase com­mit? Yes, if need­ed. In the past, this need arose out of lega­cy in­te­gra­tion. In the present and fu­ture, that need aris­es out of up-front re­quire­ments. The most typ­i­cal use cas­es are:

• Pro­cess­ing per­sis­tent mes­sages with ex­act­ly-once guar­an­tees. There is no sub­sti­tute for the re­li­a­bil­i­ty and ease of Atomikos Ex­tremeTrans­ac­tions here. Note that this can be done in­tra-process!
• Across process­es/ser­vices if you have a reser­va­tion mod­el in­her­ent in your busi­ness process. Our TCC tech­nol­o­gy will make sure that your data­base nev­er blocks.

More in­for­ma­tion about Atomikos prod­ucts can be found here