-
1. Re: Questions about transactions with core API
jbertram Apr 21, 2014 5:25 PM (in response to rcd)Typically if you want a JTA transaction inside an asynchronous client you'd use an MDB running in a Java Application Server. Otherwise you'll need to run a transaction manager on your client, manage your database and JMS connections manually, enlist all XA resources manually, etc. With an MDB you get all that for "free." The example you referenced is more of technical demonstration than a pattern you'd actually want to follow.
The thread you referenced is not discussing XA transactions. It's about a HornetQ transaction. HornetQ doesn't do anything with XA transactions automatically (unless you're using the HornetQ JCA RA e.g. with an MDB in a Java EE container).
-
2. Re: Questions about transactions with core API
rcd Apr 21, 2014 5:46 PM (in response to jbertram)This is running in an application server (WildFly) and I considered using MDBs, but that is not a viable option as far as I can tell. I need to be able to receive messages from queues/topics that are created and named at runtime, and MDBs don't allow you to do that as far as I know. The JMS API also has MessageConsumer.setMessageListener() but the Javadoc says you're not allowed to use that in an EE environment. So I don't know how I'd go about receiving messages asynchronously from arbitrary queues/topics using JMS in an EE environment. Hence the decision to use the core API instead.
I know that the thread I referenced isn't discussing XA transactions, that's why I asked whether enlisting the ClientSession in an XA transaction would "tie" the HornetQ transaction to the XA transaction, and so commit/rollback on the XA transaction would also cause commit/rollback to occur on the HornetQ transaction. It looks like HornetQ starts a HornetQ transaction before calling onMessage(), is that correct?
-
3. Re: Questions about transactions with core API
jbertram Apr 21, 2014 9:35 PM (in response to rcd)The JMS API also has MessageConsumer.setMessageListener() but the Javadoc says you're not allowed to use that in an EE environment.
There are implications for threading, security, and transactions when using setMessageListener() in the EE container which is why it is not permitted.
So I don't know how I'd go about receiving messages asynchronously from arbitrary queues/topics using JMS in an EE environment. Hence the decision to use the core API instead.
One solution would be to have a master destination where all messages went and each message could have a piece of metadata (i.e. a property) which contained the information which would otherwise be inferred from its destination.
Another option would be to use a synchronous approach.
I know that the thread I referenced isn't discussing XA transactions, that's why I asked whether enlisting the ClientSession in an XA transaction would "tie" the HornetQ transaction to the XA transaction, and so commit/rollback on the XA transaction would also cause commit/rollback to occur on the HornetQ transaction.
As I understand it, the HornetQ transaction and the XA transaction are orthogonal.