You are here: Blog » Tech tips

Tech tips

The Atomikos connection pooling mechanism invalidates connections when there are any errors - just to be sure that later transactions are not corrupted by prior errors on the connection stream to the back-end. Also, sometimes connections simply time out in the back-end, and are closed without warning. So it may happen that you have some 'erroneous' connections in the pool at any given time, and you will only find out the next time you try to use one of these connections (i.e., in your application logic you will see exceptions related to this).

To avoid this (and have the pool proactively validate connections for you) just set a testQuery on the AtomikosDataSourceBean instance. The idea is that you supply a snippet of SQL code that can be used by the pool to test if the connection is still valid. If not, it will be replaced automatically - and you should never get any erroneous connection out of the pool.

The fact that the testQuery is optional has been confusing to some users. Consequently, we've been asked to make it required or default to something meaningful. We've seriously thought about this, but there are a few problems here:

  • Making it required means breaking a lot of existing, working configurations when they upgrade to our newest release. That is because these existing configurations usually do not include any testQuery settings and the new release would fail to read the configuration and initialize correctly - thereby breaking backwards compatibility. We did not want to do this.
  • Providing a reasonable default is equally difficult, if not even harder: it turns out that there is no known SQL statement that will work for all DBMS. So our default testQuery - whichever we choose - would always fail on some systems. We did not want to do this either.

So what did we do to improve this? After some input from our LinkedIn group we now have a serious warning message in the logs whenever you don't set the testQuery.

Note: this will be available in our very next release - due beginning of October.

Check out this cool blog entry on how this can all work together.

DISCLAIMER: the suggested solution has not yet been verified by Atomikos…

2018 UPDATE: the link seems to be broken by now - apologies for that.

Here is an interesting post at JBoss about configuring Hibernate, Infinispan's caching and Atomikos JTA (among other JTA implementations). Sample code and configuration files are included.

Regards

Atomikos inside web containers

15 Jun 2009 | atomikos | Tech tips
Are you looking for an open source JTA/XA transaction manager for your web container?

Although web apps are not our mainstream business, some people do value Atomikos for their web apps.

See this wiki page for configuration of Tomcat and Atomikos.

Suppose you want to develop a high-volume transaction processing system in Java/J2EE. How would you do it? Most people would say: don't use JTA/XA transactions because they kill performance. Wrong. And they would also say: use an appserver to scale. Again, they couldn't be more wrong.

Here is the magic recipe on how we build systems with virtually unlimited scalability at Atomikos:

  • Kick out your appserver as soon as you can, as explained here. J2EE is not limited to an appserver. J2EE is a set of APIs. The appserver ties these APIs to a programming model that almost nobody needs. Conclusion: drop the latter.
  • Use a persistent JMS queue to store transaction requests. This allows easy load-balancing and provides crash resilience for ongoing requests. It also de-couples the clients from the transaction processing system.
  • Use ExtremeTransactions to process the requests (stored in JMS). This allows for reliable, exactly-once message processing as outlined here. Make sure to use the supplied JMS and JDBC drivers!
  • To add more power, just add a second VM (process) on a separate CPU.
  • Repeat until performance is high enough.

You will reach the required performance because of the intra-VM nature of each process you add. The only potential bottlenecks are your own database or JMS backend. So scaling comes down to scaling your backends, which is much simpler than scaling your application itself (which has already been done in a natural way as outlined above).

So don't let anybody fool you: transactions do scale - even without limits!.

Extra: Elastic scaling

Our commercial product ExtremeTransactions includes elastic scaling features for cloud deployments. You can apply for a free trial below…

Try ExtremeTransactions For Free

Corporate Information

Atomikos Corporate Headquarters
Hoveniersstraat, 39/1, 2800
Mechelen, Belgium

Contact Us

Copyright 2026 Atomikos BVBA | Our Privacy Policy
By using this site you agree to our cookies. More info. That's Fine