CODEWITHSUNDEEP
multithreadingibm-mq
paxdiablo
paxdiablo

Reputation: 881643

Does MQ still have a limitation of per-thread connections?

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.

If you tried to do another MQCONN from a thread that was already 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.

However, if you tried to connect from a different 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.

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.

The threads will all connect using XMSFactoryFactory which supposedly provides MQ connection pooling for efficiency but, if there's still a connection-per-thread requirement and the threads themselves 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.

Upvotes: 1

Views: 2172

Answers (1)

Shashi
Shashi

Reputation: 15273

Now connection can be shared across threads. Read through this link for more information.

XMS .NET is a JMS specification implementation in C# language for communication with IBM MQ queue manager. XMSFactoryFactory does not provide connection pooling.

You should also note that as per JMS v1.1 specifications a JMS Session object and it's children (producer, consumer etc..) should not be shared across threads.

Upvotes: 3

Related Questions