5

We are backend processor and doing programming with JMS MQ. We have 2 queues. one is used to get message and another one is used to send message. All the banking users will put messages to Q1 through their IB, MB etc. We receive messages from Q1 and process it and we send message to Q2.

Currently we do not use multi threading for this. Can we able to use multi threading for this or single thread is enough to do this. because we are getting messages from Q1 one by one and process it.

Kindly revert back to me if question is not understandable. Please someone help me.

1 Answers1

6

Yes, JMS allows for multiple readers on the same queue. You can do this by multi-threading, multiple application instances, or a dispatch layer that fetches messages and then passes them to a handler through a callback or other mechanism.

The application must support that, however. For example, if two messages are related and must be processed in order, the order is not preserved if there is more than one listener on the queue. This is one reason why async messaging patterns strongly prefer messages not to have order dependencies or affinities.

If you use multi-threading, it is important to make sure to preserve transactionality. If multiple threads use the same connection and one issues a COMMIT then that commits all outstanding messages across all the threads sharing that connection.

T.Rob
  • 31,522
  • 9
  • 59
  • 103
  • Thank you for your answer Rob.. So we need to use new connection for every thread right. –  Jan 25 '17 at 06:33
  • If it's transactional you need to ensure that the scope of the transaction and the scope of the threads matches. That usually means connection per thread. if it isn't transactional it doesn't matter. Without knowing the business requirement, there's no definitive answer to that question. There's a great compilation of MQ 'Getting Started" info if you hover over the [tag:ibm-mq] tag and click `info`. – T.Rob Jan 25 '17 at 15:48
  • Thank you Rob, i am sorry for asking this question. How do i know transactional or non-transactional. my business requirement is : client will put xml as messages in the queue. say for example cutsomer balance enquiry. server will process this in back-end and provide response to client [another queue] with customer balance details. –  Jan 27 '17 at 05:11
  • 1
    If the app cannot lose any messages you want transactional and persistent messages. MQ provides a single-phase commit for this. If the app cannot get dupes, you probably want XA style two-phase commit transactions. From the perspective of a developer of async messaging you should become familiar with the classes of service available and how to achieve those. The main ones are best effort, at least once, at most once, and once and only once delivery. See also [Transaction support](http://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.pro.doc/q003570_.htm). – T.Rob Jan 27 '17 at 12:40
  • 1
    Also have a look at [Enterprise Integration Patterns](http://www.enterpriseintegrationpatterns.com/patterns/messaging/) web site and buy or borrow a copy of the book, – T.Rob Jan 27 '17 at 12:42