| Author |
Message
|
| yslee2 |
 Posted: Wed Mar 19, 2008 1:22 am Post subject: MQ Thread-safe? |
 |
|
Newbie
Joined: 10 Jul 2006
Posts: 8
|
Can multiple threads share the same connection handle?
To be more specific, can both threads get messages at the same time using the same connection without waiting another to return first? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Mar 19, 2008 1:27 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
No.
You can (using MQCONNX) create a shared connection in one thread that's in scope to other threads but the get calls will either stack up and wait or fail immediately depending on the options you set. That's seldom useful behavior.
If you want to issue 2 simultanious gets from 2 threads you need 2 connections.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Mar 19, 2008 2:49 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Well it is actually useful, if you want to manage a pool of connection handles amongst your worker threads. This can be useful to keep the connection numbers down to conserve channels.
If the application is mainly waiting for messages with MQGET WAIT then sharing handles doesn't help. But for other types of design it can reduce the concurrent connections.
However you then have to implement logic to locate a free handle either by keeping track yourself, or perhaps trying one of the handle pool at random until you find one that is free. Hence the need for a failure if in use return code.
Of course this is mainly useful for MQ client connections. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Mar 19, 2008 2:56 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| Well it is actually useful, if you want to manage a pool of connection handles amongst your worker threads. This can be useful to keep the connection numbers down to conserve channels. |
This is why I specifically mentioned get calls.
In these enlightened days of course, no one manages a pool of connections; they get the app server to do it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 19, 2008 6:09 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| if you want to manage a pool of connection handles amongst your worker threads |
I suppose this fits into the category of a solution for which there is no problem. Yes, it can be done technically - and what fun it would be.
_________________
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 |
|
|
| zpat |
| Posted: Wed Mar 19, 2008 6:34 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Not so, we have application servers with many threads and we use client connections to a shared queue manager. We don't want each thread to have it's own handle because we will run out of storage on the queue manager trying to handle thousands of client channel connections.
We don't use transaction managers or commercial application server environments like WAS to handle these connections for various historic reasons.
In any case someone has to code the application server itself and therefore needs this feature in the MQI. In effect we have written our own.
In fact right now we have this problem with one application that doesn't pool the connections and is breaking our queue manager limits! |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Mar 19, 2008 7:05 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| zpat wrote: |
| In fact right now we have this problem with one application that doesn't pool the connections and is breaking our queue manager limits! |
Just curious zpat, what do you have your QM's Max Active Channels set to?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 19, 2008 7:08 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| because we will run out of storage |
I appologize. I'm not implying that this is a bad solution, only that it is a solution. It may have been the best of the possible solutions available to you at the time the problem was observed.
Quite a while ago I worked for a manager that would challenge me (us) by asking us to 'name five ways' to solve the problem at issue. It was a jarring event the first time he did it.
His purpose was to get us looking at the bigger picture, the long-range solution that better fit the business, not just the technology problem at hand. Our IT shop was there to push $15M through its business systems each day, and not in the business of writing transaction-manager code, or data compression code, or encryption code. We were capable of doing so, but it was not in the mission-statement.
This manager demanded that we propose short-term, mid-term and long-term solutions. Over time we had lots of wonderfully creatinge technical code, but we ended up having to maintain it as we moved forward through iterations of IBM- and OEM-provided subsystems like MQ.
My point here is that it may make more business sense to buy more storage or buy a transaction manager or whatever.
In one of my every-90-day performance/goal setting sessions,a mid-level managers once chided me (and my technical team) for not rewriting the vendor-supplied device-drivers to make them more efficient. My response to him was that we are not in that business.
_________________
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 |
|
|
| zpat |
| Posted: Wed Mar 19, 2008 7:17 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Most of our MQ adapters use some common Java code, this has been around for over 10 years and works well.
If we were starting again we would use EJBs no doubt. But often we inherit bits of code from vendors or from acquistions.
With .Net we are using the IBM supplied .Net trigger monitor (MQ V6) which provides connection pooling logic.
I would always recommend buying infrastructure function than writing our own, but sometimes it's just not possible at that time.
We were given an IBM award in 1995 for our use of MQ on the Internet which shows how long we have been at it, back then we used CGI, REXX, MQ, OS/2, SNA and IMS.. ! |
|
| Back to top |
|
|
|
|
