| Author |
Message
|
| jackie |
 Posted: Fri Jun 20, 2003 7:57 am Post subject: Persistent queue |
 |
|
Novice
Joined: 01 Jun 2003
Posts: 20
Location: NYC
|
I thought about it and asking you guys insight.
why do you use persistent queue? I see that if you can use certain trigger in case of failure to reroute or to initiate any back process, i don't see any reason to have persistent queue.
there might be some performance penalty related with having persistent queue, but this can be very minimal, too.
your thought on that,
thanks. |
|
| Back to top |
|
 |
| mqonnet |
| Posted: Fri Jun 20, 2003 8:14 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Persistence is NOT an attribute or feature of a queue. It is of a message. Defining a queue as persistent doesnt make the messages landing on that queue persistent. It is the Md that decides what type of message is put on that queue.
Not sure what your question is.
But the very idea of having persistent messages is assurance. First of all, the delivery is assured and secondly you do have them even after a qm restart.
Cheers
Kumar |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Jun 20, 2003 10:51 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Persistence is a queue attribute, you set the default persistence if the message MQPUT does not specify what it should have.
Some installations like to leave the persistence mode to default to the queue setting. I personally think the application should set it explicitly.
Use persistent messages if you want recovery over QM restarts. Typically used for "datagram" updates that are processed asychronously. Use non-persistent for "request reply" messages that are processed synchronously by the application (and these should also expire if not received in time).
Performance is much better with non-persistent messages, so use these unless you are relying upon MQ to recover messages over restarts etc. Normally an application would use NP messages to query a database or system and then issue any final update with a Persistent message. |
|
| Back to top |
|
|
| mqonnet |
| Posted: Fri Jun 20, 2003 11:09 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Zpat, i completely disagree with you on this.
Persistence is NOT a queue attribute. It is an attribute of the message. Even if you have set your queue to be persistent, if you do not explicitly modify the MD during the put, the message would still be NPM. Unless you explicitly again, code in your app, persistent_as_q_def. It is ALWAYS the responsibility of the app to define what type of message it is putting. Queue defintion can NEVER determine if a message it holds is persistent or NPM.
Cheers
Kumar |
|
| Back to top |
|
|
| bduncan |
| Posted: Fri Jun 20, 2003 12:47 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
I think your disagreement may just be a question of semantics... I think you would both agree with these basic facts:
There *is* a persistence attribute for a queue object.
An application must specify peristent_as_q_def for the message to inherit the persistence attribute of the queue it's being put to.
The queue's persistent attribute will always be overridden otherwise.
That being said, I think it's fair to say that persistence is a queue attribute, but that there's also a persistence attribute in every message, and this attribute always takes prescedent unless the putting application explicitly relegates persistency to the queue manager's discretion.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| mqonnet |
| Posted: Fri Jun 20, 2003 12:55 pm Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
The reason for me sticking to Persistence being an attribute of a message rather than the queue, is because it is the MD of the PUTTING app that CONTROLS PERSISTENCE. Queue has NO CONTROL on PERSISTENCE of a message and hence it cannot be termed to be the attribute of a queue.
Even when the PERSISTENCE attribute of the QUEUE need to come into picture it is the APP's MD that tells the Queue manager to do so by specifying persistent_as_q_def. Queue itself has no meaning/significance of PERSISTENT attribute.
I agree that all of us are thinking in the same lines, and its just matter of granularity and clarity.
Cheers
Kumar |
|
| Back to top |
|
|
| jackie |
| Posted: Fri Jun 20, 2003 1:34 pm Post subject: |
|
|
Novice
Joined: 01 Jun 2003
Posts: 20
Location: NYC
|
zpat,
thanks for your comment. Considering JCA or system managed transaction capability of app servers, I am thinking that it might be a good idea having all messages as non-persistent. Since there is roll-back capability EJB container provides and considering much better performance of the non-persistent messages, i am still testing my idea. The design must be emphasized how I can prevent any fail-over situation and improve scalability and so on. But I need more research on how these factors can impact MQ side design.
i appreciate you, master and grand masters, ideas and insights. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Jun 20, 2003 11:02 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Quote: |
| Persistence is NOT a queue attribute |
Obviously messages are persistent not queues, but there is a queue attribute affecting message persistence, that is beyond question.
Some sites perfer to code their apps to allow this queue value to set the persistence mode, and then use different queues for persistent and non-persistent messages. It's really a matter of style. |
|
| Back to top |
|
|
| rwa |
| Posted: Mon Jun 23, 2003 12:00 am Post subject: |
|
|
Voyager
Joined: 22 Jan 2002
Posts: 76
Location: Duesseldorf/Germany
|
Additional info to the performance of persistents.
The Queue Manager stores nonpersistent message in main memory. If the Queue Manager runs out of memory the messages are stored in a filesystem.
Persistent messages are allways stored in a filesystem.
On a SUN V880 running WSMQ 5.2 nonpersistent messages are 10 times faster as long as the messages are stored in main memory. |
|
| Back to top |
|
|
|
|
