Who said distributed transactions would cost in terms of performance? Now you can go as fast as with plain JDBC!
Our GitHub benchmark repo contains performance benchmarking code to test the relative overhead of JTA/XA transactions versus regular JDBC transactions. We do this by comparing a similar application scenario with a JTA/XA pool versus with a regular JDBC pool. Both are connected to a PostgreSQL database.To make sure that the comparison makes sense, we use only one datasource so we are comparing similar things: it would not make sense to compare the full two-phase commit to regular JDBC. However, it does make sense to compare the XA overhead of a 1-phase commit scenario to the performance of a non-XA application with a state-of-the art JDBC pool.
What we found is that the overhead of JTA/XA is negligible in case of network delays to the backend resource (i.e., not using a collocated DBMS). When collocated, JTA/XA results are a bit slower - probably because connection reuse is delayed until the transaction completes (which takes slightly longer than with plain JDBC, thereby making the pool less efficient) and because our open source product includes some logging overhead that is reduced in our commercial products.
Here are the detailed measurements:
Pool used | XA? | Average performance (transactions per second) | Standard deviation |
---|---|---|---|
Atomikos | YES | 310 | 40 |
DBCP | NO | 300 | 40 |
Hikari | NO | 320 | 60 |