How should I code transacted HA-JMS sender and receiver non-EJB clients deployed within a cluster of JBoss containers?
The question is tricky because: we're using JBoss 4.2.3 in "all" configuration, but would like to upgrade to 5.1 without code changes; the clients are SAR deployments of custom MBeans; no EJB/MDB whatsoever.
Various informal documentation I've been able to scrape from the web suggests looking up the ConnectionFactory from local (non-HA) JNDI with name "java:/JmsXA" and looking up the Queue from HA-JNDI.
JmsXA is not working because evidently (and as it's name suggests) it is an XAConnectionFactory, and the code:
QueueSession session =
…is not actually honoring the transcted/mode arguments (javadoc: "usage undefined"¹). This becomes a problem when the receiver code issues session.commit() or session.rollback() which raise the exception "TransactionInProgressException: Should not be call from a XASession".
I've searched for examples of using XASession from a non-EJB client and haven't come up with anything. I suppose I could try experimenting with session.getXAResource², but first problem faced would be how to allocate Xid objects, and then I imagine there will be failures because the underlying DataSource isn't XA (MySQL Cluster/NDB storage engine doesn't support XA).
Avoiding the XA mess and trying ConnectionFactory lookup with JNDI name "java:/ConnectionFactory" isn't working either: this object only exists on the master nodes local JNDI, it's not exported to HA-JNDI. I suppose I'll have to do remote JNDI connection to the master node? That sounds awful since I'll also need to detect and reconnect on master node failover.
Does JBoss 5.1 / JBoss Messaging "fix" any of this? I could change targets but I'm having massive interoperability problems between 4.2 and 5.1 in other applications (several clusters with total of 300+ JBoss application servers, "fork-lift" upgrade of our applications isn't
Any advice would be much appreciated!