Un­lim­it­ed scal­ing, easy!

Sup­pose you want to de­vel­op a high-vol­ume trans­ac­tion pro­cess­ing sys­tem in Java/J2EE. How would you do it? Most peo­ple would say: don't use JTA/XA trans­ac­tions be­cause they kill per­for­mance. Wrong. And they would also say: use an appserv­er to scale. Again, they couldn't be more wrong.

Here is the mag­ic recipe on how we build sys­tems with vir­tu­al­ly un­lim­it­ed scal­a­bil­i­ty at Atomikos:

• Kick out your appserv­er as soon as you can, as ex­plained here. J2EE is not lim­it­ed to an appserv­er. J2EE is a set of APIs. The appserv­er ties these APIs to a pro­gram­ming mod­el that al­most no­body needs. Con­clu­sion: drop the lat­ter.
• Use a per­sis­tent JMS queue to store trans­ac­tion re­quests. This al­lows easy load-bal­anc­ing and pro­vides crash re­silience for on­go­ing re­quests. It also de-cou­ples the clients from the trans­ac­tion pro­cess­ing sys­tem.
• Use Ex­tremeTrans­ac­tions to process the re­quests (stored in JMS). This al­lows for re­li­able, ex­act­ly-once mes­sage pro­cess­ing as out­lined here. Make sure to use the sup­plied JMS and JDBC dri­vers!
• To add more pow­er, just add a sec­ond VM (process) on a sep­a­rate CPU.
• Re­peat un­til per­for­mance is high enough.

You will reach the re­quired per­for­mance be­cause of the in­tra-VM na­ture of each process you add. The only po­ten­tial bot­tle­necks are your own data­base or JMS back­end. So scal­ing comes down to scal­ing your back­ends, which is much sim­pler than scal­ing your ap­pli­ca­tion it­self (which has al­ready been done in a nat­ur­al way as out­lined above).

So don't let any­body fool you: trans­ac­tions do scale - even with­out lim­its!.

Ex­tra: Elas­tic scal­ing

Our com­mer­cial prod­uct Ex­tremeTrans­ac­tions in­cludes elas­tic scal­ing fea­tures for cloud de­ploy­ments. You can ap­ply for a free tri­al be­low...

Try Ex­tremeTrans­ac­tions For Free