| Author |
Message
|
| bvasanth |
 Posted: Thu Aug 26, 2004 2:04 am Post subject: Caching Queue Manager |
 |
|
Apprentice
Joined: 03 May 2004
Posts: 27
Location: Chennai, India
|
Hi,
I am developing a J2EE based web application using MQ as key back-end part. When user does some action, I open MQQueueManager, the request, reply queues, and finally disconnect/closes them all. The opening of MQQueueManager takes lot of time (about 3-7 seconds) as I connect to remote machine.
Is it okay to open one queuemanager and keep in application-wide memory (caching), and use the same queue manager for all usre requests? Or should I always open and disconnect a queue manager for every request and it should not be shared?
Thanks
Vasanth |
|
| Back to top |
|
 |
| PGoodhart |
| Posted: Thu Aug 26, 2004 4:20 am Post subject: |
|
|
Master
Joined: 17 Jun 2004
Posts: 278
Location: Harrisburg PA
|
It is generally smart to implement a connection pool in Java. You may be able to find a sample program that implements this if you look. You will never be able to get rid of 3-7 second time it takes to connect so you should reuse the connection.
_________________
Patrick Goodhart
MQ Admin/Web Developer/Consultant
WebSphere Application Server Admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Aug 26, 2004 4:51 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you're really developing a J2EE web application, you should strongly consider using JMS instead of the base Java MQ API.
Then you will not have to worry about connection pooling, as your app server will handle it for you.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Tibor |
| Posted: Mon Aug 30, 2004 2:55 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| jefflowrey wrote: |
If you're really developing a J2EE web application, you should strongly consider using JMS instead of the base Java MQ API.
Then you will not have to worry about connection pooling, as your app server will handle it for you. |
topic off
Jeff,
There is other advantages for using JMS? The number of Java apps is growing in our environment and we should have to decide about supporting JMS.
Thanks,
Tibor |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Aug 30, 2004 5:09 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
JMS is part of the J2EE specification.
There are advantages and disadvantages to using it. One of the main disadvantages of using it is that it is slower (particularly using Message Driven Beans) than the plain MQ API. One of the main advantages to it is that it is somewhat simpler to code than the plain Java MQ API. It also takes much less code to handle transactions and connection pools - because the j2ee container is supposed to handle those for you (part of the reason it's slow).
But again, it is part of the J2EE specification and the plain Java MQ API is not.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Tibor |
| Posted: Mon Aug 30, 2004 5:43 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
|
| Back to top |
|
|
|
|
