title: Does MQ still have a limitation of per-thread connections?
body: <p>The last time I used MQ in anger (v6, from memory, on the HPUX platform), there was a limitation in that connections could not be shared amongst threads within a process.</p>
  
  <p>If you tried to do another <code>MQCONN</code> from a thread that was <em>already</em> connected to the queue manager, it very quickly came back with the previous handle and a warning saying it was re-using it so, provided you managed the shared connections properly, a single thread could make many connections to the same queue manager efficiently.</p>
  
  <p>However, if you tried to connect from a <em>different</em> thread in the process, that gave you a different connection handle, with all the slowness that entailed, as it had to go through all the rigmarole of IPC, security checking, running up another agent thread or process, and so on.</p>
  
  <p>The reason I ask this is that a client has been shown an architecture where threads are created on demand (C# under Windows) and they will all try to connect to the same queue manager. They're proposing to run MQ 7.5, if that's relevant.</p>
  
  <p>The threads will all connect using <code>XMSFactoryFactory</code> which supposedly provides MQ connection pooling for efficiency but, if there's still a connection-per-thread requirement and the threads <em>themselves</em> aren't being pooled, I'm concerned that MQ connection pooling may be useless due to the fact each new thread needs a new connection anyway.</p>