3 Replies Latest reply on Apr 21, 2014 9:35 PM by Justin Bertram

    Questions about transactions with core API

    Rich DiCroce Novice

      I've dug through the HornetQ documentation and examples, and I'm having a hard time figuring out what the transaction semantics of the core API are.

       

      The best information I've found is this thread, which basically says that where the core API is concerned, you're responsible for dealing with transactions. That's fine with me, but I want to use JTA to coordinate HornetQ as part of a larger transaction involving other resources (e.g. database). Based on the XAwithJTA example, which uses the JMS API rather than the core API, it looks like I need to manually enlist the ClientSession as a resource. Which is also fine, except that the example doesn't demonstrate how to do that with an asynchronous message receiver (MessageHandler in the core API).

       

      So how does that work? I can't tell whether HornetQ starts any kind of transaction before calling onMessage(), although based on the previously mentioned forum thread, it looks like HornetQ will start an internal transaction and I'm only responsible for completing it. If I enlist the ClientSession as part of a JTA transaction in my onMessage() implementation, will this tie the internal HornetQ transaction to the JTA transaction? If the destination address has redelivery configured and I roll back the JTA transaction, will the message get redelivered after the configured timeout or will it be lost?

        • 1. Re: Questions about transactions with core API
          Justin Bertram Master

          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
            Rich DiCroce Novice

            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
              Justin Bertram Master

              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.