| Author |
Message
|
| gifs71 |
 Posted: Thu Aug 05, 2004 12:22 pm Post subject: Multi-threaded Java app and Unit of Work |
 |
|
Novice
Joined: 05 Aug 2004
Posts: 13
|
Hi,
I have a question about using MQSeries with Java. I am using MQ base Java.
As per our application requirements, I need to process multiple messages from MQ concurrently and hence need a multi-threaded application. I have an architecture where a master thread uses multiple connections to the same queue and uses each connection to get (with a sync point) a message from queue. It then dispatches the connection
handle and the message to different worker threads for processing the message and then those worker thread either commit or rollback the get based on if the message was successfully processed or not.
Now my questions are:
1.) Is it legal that the get is done by one thread (master)
and the commit/rollback is done by another thread (worker).
2.) Is there any other better way of doing this?
Also, I have heard conflicting views on using MQBEGIN from MQ base Java as the client. Is it true that MQBEGIN cannot be used for a 2-phase commit using the MQ base Java but it could possibly be used to mark the start of a transaction from a client?
Last question, say an app does two MQGET (with sync point and using the same HCONN) one after the other and then does a single MQCMIT or MQBACK. Would the commit or rollback happen only for the last MQGET or both?
How would it be different if the app uses a different HCONN for each MQGET and then does a MQCMIT/MQBACK using
just one HCONN. Would both the MQGET commit/rollback or just the one MQGET that is associated with the HCONN used to commit/rollback.
Will really appreciate any help.
Thanks.
Rahul. |
|
| Back to top |
|
 |
| gifs71 |
| Posted: Thu Aug 05, 2004 12:28 pm Post subject: |
|
|
Novice
Joined: 05 Aug 2004
Posts: 13
|
Hi All,
Just to clarify my earlier post, by HCONN I meant a connection handle. I used both the terms interchangeably.
Also, in all the above scenarios I am working with a single queue whether it be a single HCONN or more than one HCONN.
Thanks.
Rahul. |
|
| Back to top |
|
|
| jsware |
| Posted: Fri Aug 06, 2004 1:44 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
I don't see why you can't have a getter/dispatcher thread and separate worker/committer threads. MQ Java relaxes the restriction of only allowing the thread that connects to MQ to be the user of the connection/any child opjects (queues openned etc.) However, it does mean that you are still only processing messages as fast as the getter/dispatcher can work.
Another way to do it is to have multiple threads, each connecting to MQ and each sat waiting for a message. When a message arrives, one of the threads will wake up and process the message - the other remain asleep. Whether this is a better way of processing could be endlessly debatable.
Both mechanisms are documented and published design patterns at www.enterpriseintegrationpatterns.com (see the Competing Consumers and Message Dispatcher design patterns).
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| jsware |
| Posted: Fri Aug 06, 2004 1:47 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
Oh yes, as for your "MQBEGIN" question - MQBEGIN can be used from MQ Java using bindings mode (i.e. when running with a local queue manager) and not with client mode. MQBEGIN is not supported with MQ client unless you use the transactional client that is not available (at a charge).
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| bower5932 |
| Posted: Fri Aug 06, 2004 5:45 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
For a simple view, you can commit/rollback your units of work based on the connection handle. If you are passing work around to various threads, it is the connection handle that will be the scope of the unit of work.
The transactional client is actually called the 'Extended Transactional Client' and is available for a charge. This basically allows your WMQ client programs to be part of a two-phase commit.
http://www-306.ibm.com/software/integration/wmq/transclient.html |
|
| Back to top |
|
|
| gifs71 |
| Posted: Fri Aug 06, 2004 10:17 am Post subject: |
|
|
Novice
Joined: 05 Aug 2004
Posts: 13
|
Hi,
Thank you John and bower5932 for all the replies and clarifications. Things make more sense now.
Thanks again.
Rahul. |
|
| Back to top |
|
|
|
|
