JTA/XA re­li­a­bil­i­ty with­out the per­for­mance over­head

Distrib­uted trans­ac­tions with­out the per­for­mance cost

Who said dis­trib­uted trans­ac­tions would cost in terms of per­for­mance? Now you can go as fast as with plain JDBC!

Our GitHub bench­mark repo con­tains per­for­mance bench­mark­ing code to test the rel­a­tive over­head of JTA/XA trans­ac­tions ver­sus reg­u­lar JDBC trans­ac­tions. We do this by com­par­ing a sim­i­lar ap­pli­ca­tion sce­nario with a JTA/XA pool ver­sus with a reg­u­lar JDBC pool. Both are con­nect­ed to a Post­greSQL data­base.

To make sure that the com­par­i­son makes sense, we use only one data­source so we are com­par­ing sim­i­lar things: it would not make sense to com­pare the full two-phase com­mit to reg­u­lar JDBC. How­ev­er, it does make sense to com­pare the XA over­head of a 1-phase com­mit sce­nario to the per­for­mance of a non-XA ap­pli­ca­tion with a state-of-the art JDBC pool.

What we found is that the over­head of JTA/XA is neg­li­gi­ble in case of net­work de­lays to the back­end re­source (i.e., not us­ing a col­lo­cat­ed DBMS). When col­lo­cat­ed, JTA/XA re­sults are a bit slow­er - prob­a­bly be­cause con­nec­tion reuse is de­layed un­til the trans­ac­tion com­pletes (which takes slight­ly longer than with plain JDBC, there­by mak­ing the pool less ef­fi­cient) and be­cause our open source prod­uct in­cludes some log­ging over­head that is re­duced in our com­mer­cial prod­ucts.

Here are the de­tailed mea­sure­ments:

Pool used	XA?	Aver­age per­for­mance (trans­ac­tions per sec­ond)	Stan­dard de­vi­a­tion
Atomikos	YES	310	40
DBCP	NO	300	40
Hikari	NO	320	60

As­sum­ing a nor­mal dis­tri­b­u­tion (which we as­sert­ed with 100 test runs for each pool) this means that there is no clear dis­tinc­tion be­tween the dif­fer­ent pools - be­cause the in­ter­vals over­lap if you take the de­vi­a­tion into ac­count. The high­est per­for­mance with XA ex­ceeds the worst per­for­mance with non-XA pools. So there is no re­al­is­tic way of claim­ing that XA is slow­er than the oth­er use cas­es. Over­all, this sug­gests that for re­al­is­tic sce­nar­ios (where the back­end is sep­a­rate from the ap­pli­ca­tion) there is vir­tu­al­ly NO over­head in us­ing JTA/XA. So you ba­si­cal­ly get re­li­a­bil­i­ty for free!

If you want even more per­for­mance im­prove­ments, check out our com­mer­cial of­fer­ing: Ex­tremeTrans­ac­tions.