| Author |
Message
|
| iavork |
 Posted: Tue Dec 19, 2006 4:07 am Post subject: MQCMIT in cluster |
 |
|
Newbie
Joined: 10 Apr 2006
Posts: 9
|
We have a cluster environment established. We run several C++ single thread applications that listen on a cluster-shared queue. All they issue MQGET with MQGMO_SYNCPOINT. After the message is processed, we call MQCMIT to clear the message from the queue.
There are some messages (about 10% when the volume is big!) that are processed in near the same time by two different applications. My assumption is that the Queue Manager makes some internal rollbacks, so that the message is visible for the other application and then we commit nothing. Without a cluster everything is fine!
- This problem is similar to this one, but there is no solution posted (http://www.mqseries.net/phpBB2/viewtopic.php?t=4462&highlight=mqcmit)
- Can we use MQGET with MQGMO_SYNCPOINT to establish a transaction in cluster environment or we must use MQBEGIN?
- How can this be possible? |
|
| Back to top |
|
 |
| wschutz |
| Posted: Tue Dec 19, 2006 4:28 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Interesting problem....
MQBEGIN should only be used if WMQ is co-ordinating updates with a database. Is that the case??
How can you be sure that you are processing the same message twice?
Is this a recent version and csd level of WMQ?
_________________
-wayne |
|
| Back to top |
|
|
| iavork |
| Posted: Tue Dec 19, 2006 5:18 am Post subject: |
|
|
Newbie
Joined: 10 Apr 2006
Posts: 9
|
We have Oracle as database and we don't use XA to synchronize the commits. What happens:
At instance 1:
MQGET with MQGMO_SYNCPOINT => message
storing some records in Oracle
MQPUT with MQGMO_SYNCPOINT for the reply
commit Oracle and straight after that MQCMIT
At instance 2, at near the same time:
MQGET with MQGMO_SYNCPOINT => same message
attempt to store the same records in Oracle => unique key violation!
MQPUT with MQGMO_SYNCPOINT
rollback Oracle and straight after that MQCMIT for the reply
I never had this problem with one queue manager nor with connected queue managers without a cluster, but with cluster it appears too often.
I guarantee I don't issue MQBACK, nor the same message is placed twice in the queue.
What I met in the documentation is the difference between "Queue-manager-coordinated local unit of work" (this is what I think I use when I call MQGET with MQGMO_SYNCPOINT?) and "Queue-manager-coordinated global unit of work" (with MQBEGIN?), but I am not sure this is the problem and would help me?
The MQ version is 6.0.0.0. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Dec 19, 2006 5:36 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you have two MQGets waiting on a queue, they will never be given the same message even if the same message is "available" to both GETs.
If you can prove that they are, you can open a PMR. This is probably harder than you think it is.
It may simply be that your Oracle unique keys aren't unique enough, or that you aren't creating them uniquely enough - for example if you're using a timestamp and you're only counting in seconds and not subseconds.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| iavork |
| Posted: Tue Dec 19, 2006 6:11 am Post subject: |
|
|
Newbie
Joined: 10 Apr 2006
Posts: 9
|
Well, I have 3 MQGET waiting on the queue and many messages placed. They don't get the same message in the same time, but *near* the same time. I doubt MQ issues some internal rollback during the processing of the message (during the Oracle operations) so it becomes visible for the second application and it grabs and starts processing. The database constraints are OK - I have the messages spooled in the log file of the applications and they are exactly the same, also the key values that causes Oracle first to synchronize and then reject the processing and prevent us from duplicate input.
I can't explain how MQ could rollback the message - I don't invoke MQBACK, nor have any other abnormal event nor any MQ return code. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Dec 19, 2006 6:33 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You can turn on tracing to see what MQ thinks is happening.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Dec 19, 2006 8:50 am Post subject: |
|
|
Guest
|
All MQGETs are local. The fact that the local queue is also a cluster queue should not be an issue.
If applications are MQPUTting to the same queue in syncpoint, the messages will not be visible to MQGETting applications until the putting application commits them.
If three separate applications are MQGETting from the same queue, only committed messages will be MQGETted.
Your messages are all PERSISTENT? Channel definitions have NPMSPEED(NORMAL)? |
|
| Back to top |
|
|
| tleichen |
| Posted: Tue Dec 19, 2006 12:59 pm Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
I don't have a solution to this, but have heard other instances of this mysterious phenomena before, more recently than
http://www.mqseries.net/phpBB2/viewtopic.php?t=4462&highlight=mqcmit
as listed above, so I would not discount it. If there is a programming technique that only manifests this behavior in a cluster environment, it would be interesting to know.
I just want to ride on this thread and see where it leads... 
BTW, what platform(s) are we dealing with here?
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
|
|
