Atomikos is de­signed along the ports and adapters/hexag­o­nal ar­chi­tec­ture as de­scribed here by Alis­tair Cock­burn.

Among oth­er things, this means that it is rel­a­tive­ly easy to:

• Im­ple­ment new trans­ac­tion APIs / stan­dards / mod­els
• Add new types of two-phase com­mit re­sources

Ex­am­ples of things we've been able to re­al­ize thanks to this:

• JTA (port) / XA (adapter)
• TCC (port/adapter)
• RMI (port/adapter)

The port and adapter mod­el is also an im­por­tant con­cept in the new book Im­ple­ment­ing Do­main-Driv­en De­sign. Our do­main is 2-phase com­mit. Our adapter is our Par­tic­i­pant mod­el. Our ports are all the ways you can in­ter­act with our core sys­tem.

It has hap­pened a cou­ple of times that peo­ple have asked me how to start­up only the re­cov­ery part of their ap­pli­ca­tions. While there is no built-in sup­port in Atomikos (for now), here is a way to do it with Spring:

• Con­cen­trate your DataSource, Con­nec­tionFac­to­ry and Trans­ac­tionMan­ag­er bean de­f­i­n­i­tions in one con­fig file, say in­fra­struc­ture-con­fig.xml (the term will sound fa­mil­iar to those who prac­tice Do­main-Driv­en De­sign (DDD)
• Use this con­fig file in your ap­pli­ca­tion; this is your full run­time
• Create a sep­a­rate Main that ini­tial­izes Spring with noth­ing else but this con­fig; this will be your re­cov­ery-only ru­time

Voila! En­joy...

In­ter­est­ing blog post on how to use DBCP in XA mode, with Atomikos as the JTA...

2018 up­date: the link seems to be bro­ken by now - apolo­gies for that.

The Atomikos con­nec­tion pool­ing mech­a­nism in­val­i­dates con­nec­tions when there are any er­rors - just to be sure that lat­er trans­ac­tions are not cor­rupt­ed by pri­or er­rors on the con­nec­tion stream to the back-end. Also, some­times con­nec­tions sim­ply time out in the back-end, and are closed with­out warn­ing. So it may hap­pen that you have some 'er­ro­neous' con­nec­tions in the pool at any giv­en time, and you will only find out the next time you try to use one of these con­nec­tions (i.e., in your ap­pli­ca­tion log­ic you will see ex­cep­tions re­lat­ed to this).

To avoid this (and have the pool proac­tive­ly val­i­date con­nec­tions for you) just set a testQuery on the AtomikosDataSourceBean in­stance. The idea is that you sup­ply a snip­pet of SQL code that can be used by the pool to test if the con­nec­tion is still valid. If not, it will be re­placed au­to­mat­i­cal­ly - and you should nev­er get any er­ro­neous con­nec­tion out of the pool.

The fact that the testQuery is op­tion­al has been con­fus­ing to some users. Con­se­quent­ly, we've been asked to make it re­quired or de­fault to some­thing mean­ing­ful. We've se­ri­ous­ly thought about this, but there are a few prob­lems here:

• Mak­ing it re­quired means break­ing a lot of ex­ist­ing, work­ing con­fig­u­ra­tions when they up­grade to our newest re­lease. That is be­cause these ex­ist­ing con­fig­u­ra­tions usu­al­ly do not in­clude any testQuery set­tings and the new re­lease would fail to read the con­fig­u­ra­tion and ini­tial­ize cor­rect­ly - there­by break­ing back­wards com­pat­i­bil­i­ty. We did not want to do this.
• Pro­vid­ing a rea­son­able de­fault is equal­ly dif­fi­cult, if not even hard­er: it turns out that there is no known SQL state­ment that will work for all DBMS. So our de­fault testQuery - whichev­er we choose - would al­ways fail on some sys­tems. We did not want to do this ei­ther.

So what did we do to im­prove this? After some in­put from our LinkedIn group we now have a se­ri­ous warn­ing mes­sage in the logs when­ev­er you don't set the testQuery.

Note: this will be avail­able in our very next re­lease - due be­gin­ning of Oc­to­ber.

Check out this cool blog en­try on how this can all work to­geth­er.

DISCLAIMER: the sug­gest­ed so­lu­tion has not yet been ver­i­fied by Atomikos...

2018 UPDATE: the link seems to be bro­ken by now - apolo­gies for that.