| Author |
Message
|
| vasukn |
 Posted: Thu Jan 24, 2002 12:27 pm Post subject: |
 |
|
Newbie
Joined: 20 Jan 2002
Posts: 8
|
Hi,
Is it possible to pool the MQ connections or MQQueManagers using MQSeries java ? We are using the MQ Classes in a jsp environment. Right now,for every request a new MQQueueManager object is instantiated and once the response is received, the qmanager is disconnected. (Imagine this happening for every request from every user !!). I am little concerned about the performance bottleneck in this approach. What is the best approach to improve performance.
Thanks.
-vasukn |
|
| Back to top |
|
 |
| kolban |
| Posted: Thu Jan 24, 2002 1:57 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Definetly pool the MQQueueManager objects. No question. The choice is do you do it manually or have MQ do it? See the Using Java manual for details on the MQ pooling technologies available to you. Do not instantiate a new MQQueueManager object every servlet call.
[ This Message was edited by: kolban on 2002-01-24 13:58 ] |
|
| Back to top |
|
|
| shubhrajit_c |
| Posted: Fri Jan 25, 2002 5:13 am Post subject: |
|
|
Novice
Joined: 01 Nov 2001
Posts: 14
Location: India
|
Pooling is definitely the best option ... no doubt about it.
However we used another approach which might be useful in some contexts. Our application server was Weblogic 5.1 and we used MQSeries 5.1 so to pool the QMgr objects we would have had to write our custom pooling algorithm. We were not ready to do it so we extended the QueueManager into a class called MyQueueManager which disconnects itself before GC(We overrode the finalize method() to call qmgr.disconnect() ) . Then we store the qmgr in HttpSession so we used one qmgr object per http session ...
_________________
Shubhrajit Chatterjee
http://shubhra.4mg.com
http://hum-sab.8m.net |
|
| Back to top |
|
|
| vasukn |
| Posted: Fri Jan 25, 2002 2:29 pm Post subject: |
|
|
Newbie
Joined: 20 Jan 2002
Posts: 8
|
Thanks for the reply. Now, the question is
1. How can I you make MQ manage the connections or do the connection pooling without making changes to the code ?
2. I am not writing the jsp pages. The JSP is calling our class like this :
new BPDContentManager().getContent(....);
The BPDContentManager class has a copy of MQEngine class which manages the get and put. So now, "without" having the session information at the content manager , how can I pool the connections and make it thread safe ? Any code snippets for Connection pooling ? WHat are the cons of constructing MQMessage class for each request ?
Thanks again for your help.
-vasudeva |
|
| Back to top |
|
|
| StefanSievert |
| Posted: Fri Jan 25, 2002 10:13 pm Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
Vasudeva,
I don't think you can do connection pooling or better: utilize the connection pooling that MQ5.2 provides, without application changes.
For example code, please see - as Neil Kolban suggested - the latest version of the 'MQSeries using Java' manual, Chapter 7, section on 'Connection pooling'.
This should give you the information you are looking for.
Have a good weekend, I'll have a pint now... 
Stefan
_________________
Stefan Sievert
IBM Certified * WebSphere MQ |
|
| Back to top |
|
|
| ramjet |
| Posted: Thu Mar 07, 2002 12:54 pm Post subject: |
|
|
Newbie
Joined: 06 Mar 2002
Posts: 1
|
IBM's documentation does not say whether for a given connection object in the pool , whether you can keep the handles to the queues you used to put & get the messages open as well. I am not sure if its is expensive to access Queues each time ???
I remember dealing with a custom connection pool written in java a couple of years ago where the MQQueuemanager connection object and the queues that were opened on that connection object were kept wrapped in java objects. The MQ connection object *and* the queue handles were left open. These java objects were than accessed using a standard java connection pool design pattern. (Vector or hashtable of java objects accessed by synchronized method or from a class designed as a singleton)
Also, I am not at all convinced that storing your Qmanager object in an HttpSession is a wise thing to do unless you are convinced that httpsession will not be swappped to disk at peak times. You are only supposed to store objects that can be serialized in an httpsession objects and usually connection objects especially DB connections do not fall into that category. The problem will arise when the application server swaps the httpsession to disk when it exceeds max session size. It may not be able to reinstate the serialized connection.
|
|
| Back to top |
|
|
|
|
