Announcement Announcement Module
Collapse
No announcement yet.
Using JMS and transactional components without XA Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Using JMS and transactional components without XA

    Our current environment uses EJBs with container managed transactions. I am slowing introducing Spring into the mix. One issue we are facing with our current environment is a need to manage the EJBs and a messaging mechanism in the same transaction. JMS was considered first, however, the use of EJBs and JMS together in the same transaction was requiring us to use XA, something we do not want to do for performance reasons. Is there any way for us to use Spring transaction management and JMS in the same transaction without requiring the use of XA? Thanks.

  • #2
    Spring iteself is not a transaction manager, it is simply an abstraction around many different transaction APIs including JTA. For most (all?) environments creating a transaction that spans more than one resource provider (two different dbs or a db and a message queue) means using XA transactions.

    Have you actually tested the performance of the XA transactions? You may be surprised - and if you really do need a transaction that spans many resource providers it is a good solution. You should also evaluate different JMS solutions as well as different transaction managers to see if you can increase performance.

    Rob

    Comment


    • #3
      To avoid XA

      As Rob says, if you are using multiple resources in a transaction then you've pretty much gotta use XA.

      One way to avoid this is for your transaction to just use (say) JDBC for your EJB and 'messaging', then you can use just a single regular JDBC transaction without having to pay the XA cost.

      You can still use JMS for the messaging aspect if you wish. e.g. you could use ActiveMQ with the JDBC persistence engine so that the EJBs and the JMS operations all take place on the same JDBC connection and so a single, regular JDBC transaction can be used.

      Another common technique for increasing performance of message centric processing using transactions is to batch things up. e.g. process 100 messages in 1 transaction. The cost of a transaction is in the commit (which is always a synchronous RPC with the persistence engine/transaction manager which has lots of latency); the send/receives of messages is normally asynchronous and so very fast within a transaction.

      So processing many messages in a transaction tends to make things more asynchronous and reduces the latency and so speeds things up.

      Comment


      • #4
        Thanks. I think that is exactly what I was asking for. I understand that XA is needed for multiple resources. What I was looking for was a JMS implementation that was based on the same resource (datasource) that was being used by the EJBs. I posted the question here because I was wondering if Spring was providing its own JMS implementation that may work that way. I now realize it does not but if I understand you correctly, ActiveMQ does. I will look into it.

        Comment


        • #5
          Yes it should work with ActiveMQ. A few things to bear in mind...

          * you need to use the JDBC PersistenceAdapter with the same DataSource as your EJB/ O/R layer with the same physical Connection used per thread

          * you need to deploy ActiveMQ with an embedded broker, so that the broker-side message persistence occurs in the same thread as the JMS client send() calls.

          * ensure that the vm://localhost transport is used in the JMS ConnectionFactory to connect to the embedded broker and that you are not setting the asynchronous send flag.

          If you follow the above it should work. Do let us know how you get on; I'm sure we could make it a little easier to do the above

          Comment


          • #6
            Originally posted by jstrachan
            Yes it should work with ActiveMQ. A few things to bear in mind...

            * you need to use the JDBC PersistenceAdapter with the same DataSource as your EJB/ O/R layer with the same physical Connection used per thread

            * you need to deploy ActiveMQ with an embedded broker, so that the broker-side message persistence occurs in the same thread as the JMS client send() calls.

            * ensure that the vm://localhost transport is used in the JMS ConnectionFactory to connect to the embedded broker and that you are not setting the asynchronous send flag.

            If you follow the above it should work. Do let us know how you get on; I'm sure we could make it a little easier to do the above
            How should a recipient behave in this scenario?

            Comment


            • #7
              I'm curious if the addition of the journaled JDBC adapter has any bearing on this. That is, should I still use the straight-up JDBC adapter or could I use the journaled version to achieve the same outcome in terms of transaction rollback? Also, given that it's been four years since this thread was started is there anything else that's changed in with ActiveMQ or Spring that affects the approach outlined above?
              Last edited by robmoore; Apr 4th, 2008, 07:41 PM.

              Comment

              Working...
              X