4 Replies Latest reply on Nov 4, 2013 3:58 PM by Koen Janssens

    useLocalTx semantics

    Koen Janssens Newbie

      I'm looking at improving our hornetq performance by 'disabling' the XA disk logging overhead. In jboss 5, this was possible by enabling 'volatile' storage for the transaction manager. Jboss 7 does not seem to have that capability.

      That triggered me to use the 'useLocalTx' flag of the hornetq ra adapter (pooled-connection-factory/inbound-config/use-local-tx). I was hoping this would reduce the XA logging done by arjuna.

      And it does. However, i was not quite sure what exactly happened behind the scenes.

       

      After some tests, it seems that transacted messages (MDB with @Required annotation) are not ack'ed (and stay on the queue) if the useLocalTx is enabled. I was hoping that a 'local' resource would be registered to the JTA transaction, but apparantly nothing gets registered at all and the messages are not acked at all.

       

      For non transacted messages (eg @NotSupported), all works well since hornetq will explicitly start/commit a hornetq local transaction for each message (No JTA integration).

       

      I'm using hornetq 2.3.5

        • 1. Re: useLocalTx semantics
          Andy Taylor Master

          setting localtx to true simply means the resource adapter will use a non xa jms tx and rollback or commit that on the jms session using a JMS transaction. It has no connection at all with JTA so you should use NotSupported if you dont have any other xa stuff going on.

          • 2. Re: useLocalTx semantics
            Koen Janssens Newbie

            I was hoping the 'use-local-tx' flag would have semantics similar to the <transaction mode="local"/> setting of 'pooled-connection-factory'. When sending a JMS message, the latter flag registers a hornetq session as a non-xa (1-phase commit) resource with an ongoing JTA transaction. So local means 'non-xa' in this context.

             

            I think there can be four different levels of 'transaction handling' for MDBs:no-tx,local-tx,non-xa,xa. Is it correct to say that only no-tx,local-tx and xa are supported today ?

             

            In our usecase, i want to use a transacted MDB (everything that happens inside my 'onmessage' handler should be atomic),but i don't want the MDB hornetq session itself to join the XA session (mainly for performance reason, XA means extra IO for the tx logs). 

            • 3. Re: useLocalTx semantics
              Andy Taylor Master

              I was hoping the 'use-local-tx' flag would have semantics similar to the <transaction mode="local"/> setting of 'pooled-connection-factory'. When sending a JMS message, the latter flag registers a hornetq session as a non-xa (1-phase commit) resource with an ongoing JTA transaction. So local means 'non-xa' in this context.

              nope, like I say it just an internal flag for how we create and use a session in the RA.

              I think there can be four different levels of 'transaction handling' for MDBs:no-tx,local-tx,non-xa,xa. Is it correct to say that only no-tx,local-tx and xa are supported today ?

              Im not reeally sure what you mean here, supported by whom, surely non xa is just using NOT_SUPPORTED.

              In our usecase, i want to use a transacted MDB (everything that happens inside my 'onmessage' handler should be atomic),but i don't want the MDB hornetq session itself to join the XA session (mainly for performance reason, XA means extra IO for the tx logs).

              is there a big difference? also you do realise that you may get duplicate deliveries on server failure?

              • 4. Re: useLocalTx semantics
                Koen Janssens Newbie

                By non-xa i mean the hornetq session would join the JTA transaction (started since the message is transacted) as a 'local' resource, not an XA-resource. I'm aware that it does not support 2PC and it does not offer the same 'robustness' as an XA resource, but it does scale a lot better. (XA transaction log a bottleneck since we have a lot of small messages in our system)

                 

                Anyway. At least I understand better how the current implementation works. I still think it's a bit weird that hornetq will 'silently' keep messages on the queue after they are handled if an MDB is transacted and the use_local_tx flag is set. If this is a wrong configuration, better make that clear by raising an exception.

                 

                Regards,

                Koen