Re: browse question

[Miller, Dennis]

Title: Message

Yikes.  I think it is a good practice to routinely restart the browse first after you get to the end. However, this has much broader implications.  The extreme case would be a very busy queue that seldom empties? Then you have unattended messages at the top of the queue while those near the bottom are getting worked. Or, suppose app A and app B, running concurrently,  each put 2 messages within a unit of work and App C is browsing the messages. Then you could have something like this: A puts msg 1 B puts msg 2,3 and commits C browses 2,3  (note: msg 1 is skipped because it is not committed yet) A puts msg 4 and commits C browses 4 C gets 2033 and restarts browse cursor C browses 1 In this example, the put order is 1,2,3,4 but the get order is 2,3,4,1.  Messages 1 is retrieved out of sequence even though all conditions for sequential retrieval are being met! And that's assuming you deliberately restart the browse cursor. Fail to do that and msg 1 gets stranded. It gives me pause to rethink the practicality of browsing   -----Original Message----- From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Monday, October 11, 2004 5:15 AM To: [EMAIL PROTECTED] Subject: browse question Found this in the manuals... so no need for you all to go digging around now :)   Uncommitted messages An uncommitted message is never visible to a browse; the browse cursor skips past it. Messages within a unit-of-work cannot be browsed until the unit-of-work is committed. Messages do not change their position on the queue when committed, so skipped uncommitted messages will not be seen, even when they are committed, unless you use the MQGMO_BROWSE_FIRST option and work though the queue again.   Thanks Darren