Using non-XA JDBC drivers with TransactionsEssentials

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

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

NonXaDataSourceBean ds = new NonXaDataSourceBean();
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();

Note: you should be aware that connections acquired from a NonXaDataSourceBean are bound to the thread. This means that if you call twice (or more) ds.getConnection() in the same thread you will always get the same connection back:

NonXaDataSourceBean ds = new NonXaDataSourceBean();
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 c1 = ds.getConnection();
Connection c2 = ds.getConnection();

if (c1 == c2)
    System.out.println("connections are the same");
else
    System.out.println("connections are not the same");

c1.close();
c2.close();

If you execute the above example, the message connections are the same will be printed on the console. Note that you still have to call close on both Connection references, the pool will make sure that the physical connection won't be released to the pool for as long as all references did not get closed.

Caveats

NonXaDataSource 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 Atomikos NonXaDataSource 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...

-- LudovicOrban - 29 Jul 2007 -- GuyPardon - 30 Jul 2007