You can make non-XA JDBC drivers participate in XA transactions anyway by configuring a NonXaDataSource. You just have to create an instance of AtomikosNonXADataSourceBean instead of AtomikosDataSourceBean.

Here is an example of AtomikosNonXADataSourceBean creating a pool of HSQLDB connections:

AtomikosNonXADataSourceBean ds = new AtomikosNonXADataSourceBean();
ds.setUniqueResourceName("hsqldb");
ds.setDriverClassName("org.hsqldb.jdbcDriver");
ds.setUrl("jdbc:hsqldb:/the/db/path");
ds.setUserName("sa");
ds.setPassword("saPassword");
ds.setPoolSize(3);

Connection c = ds.getConnection();
 // some SQL
c.close();

Caveats

AtomikosNonXADataSource as the name suggests, is not XA compliant. Transactions executed with datasources configured in this way are not guaranteed to be atomic unless there is exactly one datasource in the entire transaction. Also, this is not an implementation of the Last Resource Gambit (or Last Resource Commit) - more on that below.

About the Last Resource Gambit

This technique involves a variation of the two-phase commit process, where (at most one) non-XA resource is allowed to determine the final outcome (commit or rollback). Contrary to popular belief, the Last Resource Commit optimization is only really safe if there is only one resource involved in the entire transaction. This implies that the AtomikosNonXADataSource approach is at least as useful (although technically slightly different). For all practical purposes, you can therefore say that Atomikos supports the equivalent of this technique: both require at most one datasource to be safe, and both allow non-XA resources to be used in the transaction…