MQSeries.net :: View topic - MQClient/Gets/Syncpoint

PeterPotkay · Posted: Tue Feb 12, 2002 10:29 am Post subject:

I did a little test where I did a get with syncpoint in a VB client. Immediately after the GET, the queue depth is zero, and I can see the message in the VB app. At this point, I have not yet closed the queue. If I abnormally end the VB app, the message gets rolled back, and the queue depth goes back to one, while the backout count on the message goes up by 1. No big deal, this works as expected.

Next, I ran the same test, except this time I got the message under syncpoint, closed the queue, and returned control and the message to the calling VB app. I ended the calling VB app abnormally, and the message went back to the queue, while the backout rose by one.

So, the third test, was get with syncpoint, close the queue, return control and the message to the calling app, destroy the reference to the VB app that has the MQ API calls by using Set oMQ = Nothing. Now if I abend the app the message does NOT get rolled back. So it looks to me that in VB, destroying the reference to the MQ VB App is what commits the messages, similar to MQDISC which does the explicit commit.

My question here is what if the calling app goes back to the VB MQ App hundreds or thousands of times before it destroys that reference? ( making a new reference, with the associated overhead of connecting to the queue manager and the Oracle databases that the VB app needs, takes to long to do every time during high volume) All these syncpoint messages are being returned back to the app, but how is MQ keeping track of them in case of a rollback?

Does it pass back a copy of the message, while the real one stays on the queue, but the depth count goes down ?

Or does it pass back the real message while at the same time writing a copy of it to the hard drive, which would then be used during roll back?

I suppose its all academic when things are working fine. I'm just worried about thousands of messages being held "somewhere" until the eventual implicit commit when the reference to the MQ API app is destroyed. Could this number get to high and cause errors?

_________________
Peter Potkay
Keep Calm and MQ On