| Author |
Message
|
| mkitclr |
 Posted: Thu Jul 26, 2012 6:00 am Post subject: Messages order Under a Syncpoint |
 |
|
Novice
Joined: 19 May 2011
Posts: 16
|
we are having multiple processes writing in to a single queue.
p1,p2,p3
p1 is using the UOW to putt messages in to a queue.
p2 is not using UOW.
p3 is using the UOW and putting messages in to a queue.
if p1 is commiting at the same time when p3 is commiting, will the messages put by p1 will be in an order for a getter?
please clarify. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Thu Jul 26, 2012 6:07 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Messages are put to a queue in order of arrival at the queue, whether in or outside a UofW. Messages in UofWs will not be visible to getting apps until they are committed.
If order of retrieval is important to your applications, then search the APR and APG manuals for order of retrieval and message groups.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jul 26, 2012 6:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The messages are put on the order that they are described to be put in the documentation.
This is a dead simple exercise to experiment with. Why haven't you experimented?
This is a dead simple case to look up in the Info center. What does it say?
It is always a bad idea to rely on the order of messages on a queue.
It is always a bad idea to have messages that exist in relationship to each other.
You should always use message groups or message segmentation to represent a stream of messages that exist in relationship to each other. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jul 26, 2012 6:12 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I don't agree that it is always a bad idea to rely on the order of messages in a queue.
If you don't use message priority or have multiple routes between queue managers, or a mixture of non-persistent and persistent messages - then the order will be maintained. Of course if you have more than one application removing them at the same time then they could be processed out of sequence.
I would imagine a very large percentage of customers rely on the order of messages when a single application is producing them and a single application is consuming them destructively. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jul 26, 2012 6:21 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
| I would imagine a very large percentage of customers rely on the order of messages when a single application is producing them and a single application is consuming them destructively. |
This is a "2 am wakeup call everything's fallen into the toilet we've lost millions of dollars" waiting to happen. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jul 26, 2012 6:57 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Explain why this is not true then.
| Quote: |
Sequential retrieval of messages
If an application puts a sequence of messages to the same destination queue, those messages can be retrieved in sequence by a single application with a sequence of MQGET operations, if the following conditions are met:
•All of the put requests were done from the same application.
•All of the put requests were either from the same unit of work, or all the put requests were made outside of a unit of work.
•The messages all have the same priority.
•The messages all have the same persistence.
•For remote queuing, the configuration is such that there can only be one path from the application making the put request, through its queue manager, through intercommunication, to the destination queue manager and the target queue.
•The messages are not put to a dead-letter queue (for example, if a queue is temporarily full).
•The application getting the message does not deliberately change the order of retrieval, for example by specifying a particular MsgId or CorrelId or by using message priorities.
•Only one application is doing get operations to retrieve the messages from the destination queue. If this is not the case, these applications must be designed to get all the messages in each sequence put by a sending application.
|
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jul 26, 2012 7:07 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| zpat wrote: |
Explain why this is not true then.
| Quote: |
Sequential retrieval of messages
If an application puts a sequence of messages to the same destination queue, those messages can be retrieved in sequence by a single application with a sequence of MQGET operations, if the following conditions are met:
•All of the put requests were done from the same application.
•All of the put requests were either from the same unit of work, or all the put requests were made outside of a unit of work.
•The messages all have the same priority.
•The messages all have the same persistence.
•For remote queuing, the configuration is such that there can only be one path from the application making the put request, through its queue manager, through intercommunication, to the destination queue manager and the target queue.
•The messages are not put to a dead-letter queue (for example, if a queue is temporarily full).
•The application getting the message does not deliberately change the order of retrieval, for example by specifying a particular MsgId or CorrelId or by using message priorities.
•Only one application is doing get operations to retrieve the messages from the destination queue. If this is not the case, these applications must be designed to get all the messages in each sequence put by a sending application.
|
|
Well you got a whole lot of conditions here.
How often are they all satisfied?
I understand that this is way more likely when dealing with a single mainframe qmgr (zOS) but as soon as you add distributed to the mix the likelihood that the conditions are met is inverse to the number of qmgrs in the network.... 
I've also seen J2EE applications using queues for the express intent of decoupling processes (no need to spawn off process internally as the queueing and J2EE framework will take care of it...) 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jul 26, 2012 7:21 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| How often are they all satisfied? |
And how often do they *stay* satisfied?
It's easy to break any of these conditions with a seemingly unrelated change... We added this qmgr to a cluster, we put a zos qmgr into a qsg, we set up an intermediate application to do security validation on all messages....
Again, i'm not looking at how full the glass is, just on how likely it's sitting on a bear trap. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jul 26, 2012 7:23 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
They are not onerous conditions at all.
It basically says if you don't mess about, you will be fine! |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jul 26, 2012 7:46 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| zpat wrote: |
They are not onerous conditions at all.
It basically says if you don't mess about, you will be fine! |
Sure, but life's all about messing about...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jul 26, 2012 9:01 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Most of my developers can barely manage to use the basic features of MQ and have never heard of things like setting message priority or matching correlid etc. So their apps will be fine.
The one I would tend to watch out for is multiple threads accessing the same queue when retrieving messages. But setting the default input option to exclusive on the queue definition would take care of that. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jul 26, 2012 9:11 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
| Most of my developers can barely manage to use the basic features of MQ and have never heard of things like setting message priority or matching correlid etc. So their apps will be fine. |
Until they forget to tell you that they are relying on put order for a message stream and you change the network configuration for an entirely unrelated project. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 26, 2012 9:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| It basically says if you don't mess about, you will be fine! |
And you don't need to mess about for it not to be fine; a number of other factors can influence it. Also what happens when you have to mess about?
The bottom line to this remains the same. If you're providing the WMQ infrastructure for a high value or business critical application that relies on order, do you want to tell the management that it should be fine just putting messages unless someone messes about or do you want to say "you need to use the WMQ facilities to ensure messages are delivered as you need"?
Maybe I'm just too old to feel excited about getting up at 2am and fiddling round in toilets.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 26, 2012 9:16 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| But setting the default input option to exclusive on the queue definition would take care of that. |
Until they tell you they've had a sales drive / bought another company and need to scale the application.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mkitclr |
| Posted: Thu Jul 26, 2012 9:56 am Post subject: Messages order Under a Syncpoint |
|
|
Novice
Joined: 19 May 2011
Posts: 16
|
|
| Back to top |
|
|
|
|
