| Author |
Message
|
| mq_techie |
 Posted: Fri Aug 25, 2006 5:51 am Post subject: Persistent messages |
 |
|
Newbie
Joined: 14 Aug 2006
Posts: 4
Location: MA
|
hi,
We have a big discussion going on here on whether persistent messaging should be handled at the application level or it should be configured at the MQ queue level. When IBM did a MQ Architecture review, they recommended that application developers should write persistent messaging in to the queue and we should not configure this at the queue level to make the messages persistent.
Any thoughts from the group on this...
Thanks! |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Aug 25, 2006 5:57 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Persistence only applies to individual messages.
Persistence should be a business level decision - how important is the message, what impact does it have if the message is lost, how fast does the message need to move through the network, how long is the message expected to stay on the system, etc.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Aug 25, 2006 6:00 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
This is an eternal debate... who do you trust more? The application developer's to properly set the persistence on the messages, or the MQ admins to properly set the default persistence on the queue (in which case, you still need to trust to app developers to use PER_AS_Q_DEF...)....
_________________
-wayne |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Aug 25, 2006 6:07 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| wschutz wrote: |
| This is an eternal debate... who do you trust more? |
It's only a debate if you view it as a technical issue.
If you view it as a business issue, then there's usually a pretty clear answer.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Fri Aug 25, 2006 8:10 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
| If you view it as a business issue, then there's usually a pretty clear answer. |
I couldn't agree more, however, if you ask the programmer their messages are always the most important and cannot possibly be non-persistent 
Getting them to admit their messages are not business critcial is like getting them to admit that they are not working on important work isn't it?  |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Aug 25, 2006 8:19 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I guess I'm just saying that one should neither ask the programmer nor the admin - but the business stakeholder.
I can see a programmer insisting that messages be non-persistent, because they must have good performance - even if the program is only producing one message a minute.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Aug 25, 2006 8:21 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Jeff & Kevin...so which do you favor? Having the programmers set persistence or using the queue default (and then having the programmer's set AS_QDEF)??
No, the question isn't: should the messages be persistent? The question is: who implements the decision?
_________________
-wayne
Last edited by wschutz on Fri Aug 25, 2006 8:22 am; edited 1 time in total |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Aug 25, 2006 8:22 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Explicit is always better than implicit.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bbburson |
| Posted: Fri Aug 25, 2006 8:24 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
| I'm not Jeff or Kevin, but I'll weigh in with my 2 cents worth. Our policy from day one has been that the queue default persistence is set to NO. It is the application's responsibility to determine and set the appropriate persistence for its messages. (And here I use "application" to include the business requirements/designers/programmers as a whole). |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Fri Aug 25, 2006 8:35 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
The application should always make the decision IMHO.
If the MQ admin tries to make it then they have to have the business savy to know what choice to really make. Usually they don't have that knowledge.
On the flip side, the business needs to at least have an understanding of what the pros and cons are for both persistent and non-persistent. They are getting there at this shop but they still have some way to go. |
|
| Back to top |
|
|
| LuisFer |
| Posted: Fri Aug 25, 2006 11:50 am Post subject: |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
| In my installation the responsability is for Bussines aplication in persistence & Convertion. We defined the q's with no persistence and channels with no convert in all cases. |
|
| Back to top |
|
|
| tleichen |
| Posted: Mon Aug 28, 2006 8:04 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
We've had both types of applications, persistent and non-persistent messaging. It really depends on who all is doing what. If the admin group has control over the applications, as well, then there is much advantage to controlling this at the admin level. We encapsulated the API, such that the applications would always wind up with AS_QDEF. This simplified things immensely and took those decisions out of the (inexperienced with MQSeries) programmers. Just my two cents. 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Aug 30, 2006 3:13 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| bbburson wrote: |
| I'm not Jeff or Kevin, but I'll weigh in with my 2 cents worth. Our policy from day one has been that the queue default persistence is set to NO. It is the application's responsibility to determine and set the appropriate persistence for its messages. (And here I use "application" to include the business requirements/designers/programmers as a whole). |
I agree.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mq_techie |
| Posted: Wed Aug 30, 2006 3:34 pm Post subject: |
|
|
Newbie
Joined: 14 Aug 2006
Posts: 4
Location: MA
|
Finally, I was able to convince our application programmers to take care of message persistence at the code level!
Thanks to everyone who responded... |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Sep 14, 2006 5:42 am Post subject: |
|
|
Guest
|
Missing from this discussion is that the programmer must set the persistence field in the message descriptor at MQPUT time to ONE of the three possible values, namely: MQPER_PERSISTENT, or MQPER_NOT_PERSISTENT, or MQPER_PERSISTENCE_AS_Q_DEF.
The so-called default attribute of the queue DEFPSIST is not a default! Rather, this attribute will set the persistence value of the message to persistent or non-persistent ONLY if the programmer specifies MQPER_PERSISTENCE_AS_Q_DEF at MQPUT time.
As a general rule, programmers should not make decisions and write code about hardware or performance. The marginal improvement in throughput with non-persistent messages is vastly outweighed by the (potential) loss of a non-persistent message that contains a billion dollar funds tranfer transaction. |
|
| Back to top |
|
|
|
|
