Shared (thread independent) connections with MQCONNX

 

Not supported on WebSphere MQ for z/OS.

On WebSphere MQ platforms other than WebSphere MQ for z/OS, a connection made with MQCONN is available only to the thread that made the connection. Options on the MQCONNX call allow you to create a connection that can be shared by all the threads in a process.

Use one of the following options to make a thread independent or shared connection:

MQCNO_HANDLE_SHARE_BLOCK Creates a shared connection on which, if the connection is currently in use by another thread, an MQI call waits until the current MQI call has completed
MQCNO_HANDLE_SHARE_NO_BLOCK Creates a shared connection on which, if the connection is currently in use by another thread, an MQI call fails immediately with a reason of MQRC_CALL_IN_PROGRESS
MQCNO_HANDLE_SHARE_NONE Creates a standard non-shared connection

In the normal MQI environment the default value is MQCNO_HANDLE_SHARE_NONE. In the MTS environment the default value is MQCNO_HANDLE_SHARE_BLOCK.

A connection handle (Hconn) is returned from the MQCONNX call in the usual way. This can be used by subsequent MQI calls from any thread in the process, associating those calls with the Hconn returned from the MQCONNX. MQI calls using a single shared Hconn are serialized across threads.

For example, the following sequence of activity is possible with a shared Hconn:

  1. Thread 1 issues MQCONNX and gets a shared Hconn h1

  2. Thread 1 opens a queue and issues a get request using h1

  3. Thread 2 issues a put request using h1

  4. Thread 3 issues a put request using h1

  5. Thread 2 issues MQDISC using h1

While the Hconn is in use by any thread, access to the connection is unavailable to other threads. In circumstances where it is acceptable that a thread waits for any previous call from another thread to complete, use MQCONNX with the option MQCNO_HANDLE_SHARE_BLOCK.

However this can cause difficulties. Suppose that in step 2 above, the thread issues a get request that waits for messages that might not have yet arrived (a get with wait). In this case, threads 2 and 3 are also left waiting (blocked) for as long as the get request takes. If you prefer that your application is notified of calls that are already running on the Hconn, use MQCONNX with the option MQCNO_HANDLE_SHARE_NO_BLOCK.

 

Parent topic:

Connecting to a queue manager using the MQCONNX call


fg12070_