Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

MQGET and nondestructive reads ? 1

Status
Not open for further replies.

corey000

Programmer
Feb 13, 2001
1
US
Hello,
I have a mulithreaded application. One thread is responsible for reading messages from a queue. Several other threads are involved in message processing. The final thread puts reply messages on a second queue.

How can I avoid losing messages within my application when it suddenly terminates? Is there a way that messages can be left on the first queue until the corresponding reply message has been put on the second?

Thanks
 
You don't say what platform you are using but the normal way would be to encapsulate all MQ operations within a Unit of Work or transaction. This is done using MQBEGIN(), specifying the SYNCPOINT option on PUT/GET or a couple of other ways on the more exotic platforms.

However, using multiple threads is going to cause you a problem since MQ connections cannot be shared across threads. Off the top of my head I would recommend this:

GET Thread: MQBEGIN (or equivalent) - Get msg
PUT Thread: Put reply msg - send IPC signal to GET thread to say all is OK
GET Thread: MQCOMMIT (This permanently removes the msg from the queue)

There is a small window here where if your app dies after sending the reply but before issuing the commit you will have acknowledged a message but will still find that message on the queue next time you look. You could check the backout count of the msg if this is a problem.

Cheers,
Paul
 
Hi Paul,

In an application which i developed different threads are
using the same MQConnection object. It still works fine.

Cheers,
Rajesh
 
I understand that IBM have made this work for Java but I don't know the details. I should have said this was a problem for the non-Java implementations.

Cheers,
Paul
 
Regarding sharing of connection handles by threads i have a clarification.
If there are two threads one that is putting message onto the out queue and another reading from the in queue then is it that they have to have separate connection handles and they cant share the same handle to read or write to the queue?
 
One other small clarification - you only need MQBEGIN if you are coordinating your unit of work with an external resource such as a database within the GET thread. Get within SYNCPOINT is all that you need to do otherwise (i.e. a query style application).

My suggestion here? Have the same thread that does the get, also do the put and commit both actions with a single MQCMIT. This will ensure that no messages are ever unprocessed.

Cheers,

Scott Meridew
Certified MQ Specialist
TxMQ Inc.
Scott Meridew
Certified MQSeries Specialist,MCSE
MQ Squared Inc.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top