| Author |
Message
|
| rangyaonmq |
 Posted: Wed Apr 22, 2009 3:11 am Post subject: MQ Queue processing Query |
 |
|
Newbie
Joined: 06 Apr 2009
Posts: 6
|
We have Application.Header and Application.Detail queues.
These queues are Local and persistent.
Processing:
We get trigger data messages on Application.Header queue.
Here we receive order numbers.
We receive the data to be updated in database or for more processing on Application.Detail queue.
So in this queue we receive 1000s of messages for a particular order number.
Depending on the order numbers we fetch the Application.Detail queue.
Query:
Say we have arround 15,000 messages on the Application.Detail queue.
We have 15 messages with 15 different order numbers on Application.Header queue.
How the order number will be searched in the 15,000 messages on Application.Detail queue. ?
Will it go from the start of the queue and look for the order one by one upto the end ? |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Apr 22, 2009 3:15 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Start over.
This is a poor design from the beginning.
One message = one total order. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 22, 2009 3:34 am Post subject: Re: MQ Queue processing Query |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rangyaonmq wrote: |
How the order number will be searched in the 15,000 messages on Application.Detail queue. ?
Will it go from the start of the queue and look for the order one by one upto the end ? |
Yes. For each of the 15,000 messages. Having found the message, you'll then need to retrieve the message under the cursor, so it then repositions itself to do the destructive read. The only exception is on z/OS where you can declare an index against either msgid or correlid.
But you're not using the order number as all or part of the msgid in a mixed platform environment. Because if you are you've not got that problem and have created a dozen or so more.
WMQ is not a database and shouldn't be used as one. Your design is bad in many, many ways.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| manicminer |
| Posted: Wed Apr 22, 2009 4:22 am Post subject: Re: MQ Queue processing Query |
|
|
Disciple
Joined: 11 Jul 2007
Posts: 177
|
| Vitor wrote: |
| WMQ is not a database and shouldn't be used as one. Your design is bad in many, many ways. |
I think this is the most important thing here (although with the 2 illustrious posters in this thread already, not sure why I'm even posting!).
The design mentioned is very typical of a header/detail database pattern. MQ isn't a database, you should design a messaging pattern not a database one 
_________________
Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 22, 2009 4:28 am Post subject: Re: MQ Queue processing Query |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| manicminer wrote: |
| with the 2 illustrious posters in this thread already, not sure why I'm even posting! |
You're underlining a point you feel needs to be emphasised because it's so important, and let's face it - illustrious? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| manicminer |
| Posted: Wed Apr 22, 2009 4:40 am Post subject: Re: MQ Queue processing Query |
|
|
Disciple
Joined: 11 Jul 2007
Posts: 177
|
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 22, 2009 4:51 am Post subject: Re: MQ Queue processing Query |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| manicminer wrote: |
Obviously I meant the that you are both an aircraft carrier..  |
Huge, bulky and heavy? We've met then.....
I personally am a submarine. My illustrious associate is more like a Transformer: more than meets the eye, and able to disguise himself...
_________________
Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Wed Apr 22, 2009 6:55 am; edited 1 time in total |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Apr 22, 2009 4:55 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
MQ is designed for transporting data which is on its way from one app to another.
Having said that IBM seem to be making it more selective in V7
| Quote: |
Message properties are a new feature of WebSphere MQ V7.0. They are
name-value pairs that are carried alongside the message body. Java Message
Service (JMS) introduced the concept of message properties, and now they are
supported directly in WebSphere MQ V7.0 as part of the MQI.
Message properties are used by message selectors to filter subscriptions to
topics or to selectively get messages from queues. Message properties can be
used to include business data or state information without having to store it in the
message data. They also give MQI Applications direct access to message
properties set by a JMS application. |
|
|
| Back to top |
|
|
| rangyaonmq |
| Posted: Wed Apr 22, 2009 5:01 am Post subject: |
|
|
Newbie
Joined: 06 Apr 2009
Posts: 6
|
Guys thanks for the responses.... I forgot to mention that
THE ORDER NUMBER MATCHING THE ENTRY IN THE HEADER QUEUE WILL BE IN THE CORRELATION ID ON THE DETAIL QUEUE TO ALLOW US TO PROCESS ONE ORDER AT A TIME. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 22, 2009 5:04 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
Having said that IBM seem to be making it more selective in V7
...
|
Granted, but I'd still question a design that used this new v7 technology to selectively read 15,000 messages from a queue one at a time. Especially matching them from a second queue. It's 30 seconds work to code an SQL Select against 2 database tables that would do this, and far faster than the queue manager would achieve it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 22, 2009 5:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rangyaonmq wrote: |
| THE ORDER NUMBER MATCHING THE ENTRY IN THE HEADER QUEUE WILL BE IN THE CORRELATION ID ON THE DETAIL QUEUE TO ALLOW US TO PROCESS ONE ORDER AT A TIME. |
As I feared. Your design goes from bad to worse, especially if you've got z/OS and any other platform in your mix.
Review your design. Do not use WMQ as a database. Do not put business data in id fields. Double do not put business data in id fields if you're using z/OS unless it's exclusively z/OS, in which case it goes back to a single don't.
And DON'T SHOUT! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Wed Apr 22, 2009 5:19 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
....and while we are at it....
| Quote: |
These queues are Local and persistent.
|
The persistency value of the queue is almost entirely irrelevant, the application will decide the persistency.
The persistency of the queue is easily overriden by the application and only comes into play when the application uses MQPER_PERSISTENCE_AS_Q_DEF |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Apr 22, 2009 5:50 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Which is the default in the MQMD and therefore often the case (and for once it's not a bad default). |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Wed Apr 22, 2009 7:55 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| zpat wrote: |
| Which is the default in the MQMD and therefore often the case (and for once it's not a bad default). |
While I agree it is not a bad default to have, I personally, believe the application should make the deliberate and considered choice on the persistency of the message rather than leave it up to the MQ admin to determine. Just my own preference, your mileage may vary. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Wed Apr 22, 2009 8:06 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
I absolutley agree Kevin. The data being sent by the application should be either persistent or not dependant upon the application context, and not the settings chosen by an MQ admin on a particular day 
I've had this debate before internally with my lazy developers. I won them round in the end |
|
| Back to top |
|
|
|
|
