| Author |
Message
|
| bartland |
 Posted: Wed May 26, 2004 3:47 pm Post subject: Threading and Get with wait |
 |
|
Novice
Joined: 04 May 2004
Posts: 15
|
Using MQAX200
In amqtan02.pdf (pg 19), it says
| Quote: |
WebSphere MQ Automation Classes for ActiveX implement a free-threading model where objects can be used between threads.
While MQAX permits the use of MQQueue and MQQueueManager objects,
WebSphere MQ does not currently permit the sharing of handles between different threads. Attempts to use these on another thread result in an error and WebSphere MQ returns a return code of MQRC_HCONN_ERROR.
........ |
Objects? Handles? Based in this and other meagre tidbits scattered aroung some other manuals, my current interpretation is object means class and handle means object. That is the MQQueue class is thread-safe but each thread must have its own instance of the class (ie object ie handle).
Is this right or wrong?
On the matter of get & wait. It seems to be an utterly useless call since there is no way of waking it up before the timeout (is this true?) - say when the app/service wants to quit. It would be better implemented as a kind of alertable event. At the moment my theads will be polling queues (one per queue since ordering is important) for messages and using alertable events to sleep between polls - not the best way really.
_________________
bruce |
|
| Back to top |
|
 |
| bduncan |
| Posted: Wed May 26, 2004 4:15 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Right.
An object (which represents a handle to a queue or queue manager) cannot be shared among threads.
And this is true of any MQ API, not just ActiveX.
On the second point, get with wait isn't useless (it just depends on your particular needs). In your case, it sounds like you need some way to interrupt, in which case there are other ways to get the MQGET call to finish early. For instance, get disabling the queue while your application is sitting in a get/wait call will force the call to return.
Simiarly, if you set the FAIL_IF_QUIESCING parameter, then shutting down the queue manager will force the MQGET call to complete early.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed May 26, 2004 4:31 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Or you can send a message to the queue that will satisfy the MQGET, and the format of this particular message will tell the app to end instead of issuing another MQGET with WAIT.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bartland |
| Posted: Wed May 26, 2004 5:46 pm Post subject: |
|
|
Novice
Joined: 04 May 2004
Posts: 15
|
hmm! So if I want the APP (which is an NT Service) to control the connect/disconnect I'd send a message to the queue from another thread. A bit roundabout but pretty good.
thanks
_________________
bruce |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed May 26, 2004 6:22 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| bduncan wrote: |
Right.
An object (which represents a handle to a queue or queue manager) cannot be shared among threads.
And this is true of any MQ API, not just ActiveX. |
Actually, this is only mostly true in 5.3. (sorry, I"ve already checked the pockets...)
5.3 introduced the notion of thread-shareable connection handles- and MTS in particular automatically creates connection handles that are shareable.
So, please double-check your documentation and look here for complaints about error code 2018. 2018 is related to trying to share an unshareable handle - as a result there's usually some associated discussion about how to share a handle...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bduncan |
| Posted: Wed May 26, 2004 10:01 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Thanks for the clarification Jeff.
Just goes to show how something is right today, wrong tomorrow 
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
|
|
