Our application needs to use two datasources: an application specific one and and a shared one. The shared datasource can, as its name indicates, be shared by multiple instances of our application.
To ensure correct behavior of transactions we'd like to use xa-datasources. However, it seems like JBoss 4.2.3.GA, wich we are using, does not provide working recovery mechanisms out-of-the-box.
So I followed the instructions of this thread: http://management-platform.blogspot.com/2008/11/transaction-recovery-in-jbossas.html and the linked documents. I took the source code of AppServerJDBCXARecovery.java attached to JBTM-441, built a jar and deployed it with the necessary entries in jbossjta-properties.xml.
So far so good, it seems to work as expected.
However, we will be deploying further instances of our application on the same server, which means there will be additional datasources.
Performing a hot deployment would not be possible in this case, since the recovery module is only initialized once during startup and thus wouldn't recognize the additional datasources. Additionally, we'd like to not make our application depend too much on server config, i.e. we'd like no to add application specific properties (like the datasource jndi name) to jbossjta-properties.xml.
So the first question is this: Is there an easy way to provide recovery for all xa-datasources that are deployed or will be deployed in one server instance?
As far as I can see, it should be possible to somehow modify AppServerJDBCXARecovery to be able to handle multiple datasources and connections and detect new datasources. However, I'm not an expert in that area and due to time restrictions it would be very risky to try and see if I can get it working.
Thus my second question: If anyone has already solved that problem or has any suggestions on a solution, would you mind to share?
To work around the problem for the time being, we'll revert to local-tx datasources, wich means we have to create a new (sub) transaction when we work on the second datasource. However, this bears some risks with respect to consistency, e.g. when the inner transaction succeeds but the outer transaction fails.
Here's my third, and slightly unrelated, question: Is using multiple transactions for accessing multiple databases in one logical transaction (i.e. one user operation) a sensible workaround?
Thanks in advance for the endurance of reading my quite lengthy post and even more thanks for your answers.