| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Sharing handle Hconn between threads of 'C' MQ appli ? |
« View previous topic :: View next topic » |
| Author |
Message
|
| KAKEZ |
 Posted: Thu Apr 24, 2003 2:51 am Post subject: Sharing handle Hconn between threads of 'C' MQ appli ? |
 |
|
Centurion
Joined: 10 Oct 2002
Posts: 117
|
Hi,
I wonder about sharing the Hconn between different threads of an Client 'C' appli and an non Client 'C' appli?
- the documentation says (Using Java manual - chapter 7 - Multithreaded programs):
<
With the C based WebSphere MQ client, this would cause a problem, because handles cannot be shared across multiple threads. WebSphere MQ classes for Java relaxes this constraint, allowing a queue manager object (and its associated queue and process objects) to be shared across multiple threads.
>
- so it is not possible to share the Hconn handle in this condition?
+ how can then the different threads work with the same Qmgr?
+ so, what might be the solution to be able to run the threads concurently in these conditions?
- if the appli is a normal one ('C' multithreaded non mqseries client application) is it then possible to share the Hconn handle?
thanks for advices,
Jack |
|
| Back to top |
|
 |
| leongor |
| Posted: Thu Apr 24, 2003 6:41 am Post subject: |
|
|
Master
Joined: 13 May 2002
Posts: 264
Location: Israel
|
You can share HConn using MQCONNX, but only with MQ 5.3.
_________________
Regards.
Leonid.
IBM Certified MQSeries Specialist. |
|
| Back to top |
|
|
| KAKEZ |
| Posted: Fri Apr 25, 2003 12:51 am Post subject: |
|
|
Centurion
Joined: 10 Oct 2002
Posts: 117
|
Hi Leonid,
thanks for replying,
- but my pb is to be able to use the same Hconn at the same time within several threads of the same process
- and the handle sharing of MQCONNX does not allow that, each thread has to wait the current thread using the Hconn handle to finish before it can uses it! - so we have serial processing and no parallel processing!
I know thet with Java that is possible, each thread defining a different Qmgr object, but that seems not possible for a C based application
Is there a solution anyway?
Jack |
|
| Back to top |
|
|
| leongor |
| Posted: Sun Apr 27, 2003 4:08 am Post subject: |
|
|
Master
Joined: 13 May 2002
Posts: 264
Location: Israel
|
Yes you're right.
IMHO the only solution then is to use separate connection for each thread.
You need to choose what is more important here for you parallel processing or saving number of connections.
_________________
Regards.
Leonid.
IBM Certified MQSeries Specialist. |
|
| Back to top |
|
|
| jsware |
| Posted: Thu May 01, 2003 12:33 pm Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
The way you're saying it works with Java is the equivalent of having a separate connection for each thread.
If you look at the Java docs, it says that access to the Queue Manager is serialised through the QMgr object in Java.
Regards
John. |
|
| Back to top |
|
|
| KAKEZ |
| Posted: Thu May 01, 2003 10:13 pm Post subject: |
|
|
Centurion
Joined: 10 Oct 2002
Posts: 117
|
Hi John,
If I understand, it means that each JAVA thread must call MQCONN to connect to the Qmgr to be able to work with it, and doing so each gets a different Hconn handle? and so the different threads can work at the same time? - finally the same as for a multithreaded 'C' based appli if we want the threads to work in parallel?
I have heard somewhere that IBM well aware of that constraint was thinking about a way where it would be possible for an appli to connect the Qmgr first, get the Hconn and all the threads be able to work in parallel sharing the Hconn - but I dont remember where!
Jack |
|
| Back to top |
|
|
| jsware |
| Posted: Sat May 03, 2003 12:23 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
I'm only aware of being able to share an HCONN value across threads in MQ 5.3. And that is still with the restriction of only one call outstanding at any one time. The handle sharing options allow a call to either block (wait) until the other call completes, or fail with an MQRC_CALL_IN_PROGRESS return code. See the MQCONNX documentation in the Application Programming Reference guide under MQ 5.3. An excert is below:
-----
Handle-sharing options: The following options control the sharing of handles between different threads (units of parallel processing) within the same process. Only one of these options can be specified.
These options are supported in the following environments: AIX, HP-UX, OS/400, Solaris, Linux, Windows.
MQCNO_HANDLE_SHARE_NONE
No handle sharing between threads.
This option indicates that connection and object handles can be used only by the thread that caused the handle to be allocated (that is, the thread that issued the MQCONN , MQCONNX , or MQOPEN call). The handles cannot be used by other threads belonging to the same process.
MQCNO_HANDLE_SHARE_BLOCK
Serial handle sharing between threads, with call blocking.
This option indicates that connection and object handles allocated by one thread of a process can be used by other threads belonging to the same process. However, only one thread at a time can use any particular handle, that is, only serial use of a handle is permitted. If a thread tries to use a handle that is already in use by another thread, the call blocks (waits) until the handle becomes available.
MQCNO_HANDLE_SHARE_NO_BLOCK
Serial handle sharing between threads, without call blocking.
This is the same as MQCNO_HANDLE_SHARE_BLOCK, except that if the handle is in use by another thread, the call completes immediately with MQCC_FAILED and MQRC_CALL_IN_PROGRESS instead of blocking until the handle becomes available.
A thread can have zero or one nonshared handle:
Each MQCONN or MQCONNX call that specifies MQCNO_HANDLE_SHARE_NONE returns a new nonshared handle on the first call, and the same nonshared handle on the second and later calls (assuming no intervening MQDISC call). The reason code is MQRC_ALREADY_CONNECTED for the second and later calls.
Each MQCONNX call that specifies MQCNO_HANDLE_SHARE_BLOCK or MQCNO_HANDLE_SHARE_NO_BLOCK returns a new shared handle on each call.
-----
Hope this helps...
John. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
