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

    useLocalTx semantics

    janssk77
    janssk77 Nov 4, 2013 8:42 AM

      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
          ataylor
          ataylor Nov 4, 2013 9:17 AM (in response to janssk77)

          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.

            • Actions
          • 2. Re: useLocalTx semantics
            janssk77
            janssk77 Nov 4, 2013 10:11 AM (in response to ataylor)

            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). 

              • Actions
            • 3. Re: useLocalTx semantics
              ataylor
              ataylor Nov 4, 2013 10:48 AM (in response to janssk77)

              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?

                • Actions
              • 4. Re: useLocalTx semantics
                janssk77
                janssk77 Nov 4, 2013 3:58 PM (in response to ataylor)

                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

                  • Actions