T.rob,
If many ways a queue is similar to a random access file, where a message
can be read sequentially, or via a "key",deleted (destructive read) and
written by one or more apps. Normally, when a file is being updated,
exclusive control is established beforehand to ensure the integrity of the
operation. What if Roger did the following:
1. browse till he found the(starting) essage he wants
2. record the "key" (msgid) of the message
3. reopen the queue with exclusive control
4. perform the destructive gets, using the msgid he store earlier to
establish his position
This would effectively prevent new messages from being inserted in the
queue, which could effect his logical view of the message order. I haven't
tried it out, so it's simply a "what if" proposition. One drawback is the
small window that's opened between the close and re-open of the queue for
exclusive control, where messages could be inserted/gotten.
"Wyatt, T.rob"
<[EMAIL PROTECTED]
OFAMERICA.COM> To
Sent by: MQSeries [EMAIL PROTECTED]
List cc
<[EMAIL PROTECTED]
n.AC.AT> Subject
Re: Message under cursor
08/02/2004 11:37
AM
Please respond to
MQSeries List
<[EMAIL PROTECTED]
n.AC.AT>
> What I am trying to figure out is: How do you move
> the destructive get cursor?
> i.e.
> How do I position the destructive get cursor at
> message #5 without first deleting messages #1,2,3
> and 4?
Roger,
Short answer - you don't. The type of GET you are using always operates at
the head of the queue. Intuitively one would suppose no cursor would be
necessary for this operation. The fact that one exists and the discussion
in the APR suggest there would be an operation to move it but this is not
the case.
The non-browse cursor (and the lack of an operation to position it) make
more sense in the context of multiple concurrent users, logical ordering
and/or priority delivery. When you do a GET, the cursor works it's way
down the queue skipping any messages under synchpoint, deleting any expired
messages and, when logical ordering is used, skipping otherwise eligible
messages looking for the first message in a group. On top of all that, the
QMgr needs too be able to insert messages into the queue that are of a
higher priority than the message under the GET cursor. This creates a case
where inserts cause the GET cursor position to change relative to the
*start* of the queue but not to the end.
So the non-browse cursor is really there for the QMgr to manage internal
structures and make them appear (possibly to many simultaneous threads) as
a sequential queue of messages when in fact they are not. There is no
concept of a "next message" as in a sequential file because the cursor
position changes relative to both the beginning and end of the queue at any
given moment and even iterates backwards to traverse an out-of-order
logical group.
If you think about it, you don't *really* even get to position the browse
cursor. When the GET occurs - whether it's in a browse context or not -
the QMgr decides what the next message is and that's where your cursor is
set. Depending on your options, the cursor may have advanced or retreated
in the queue, you don't really know and it's not decided until the call is
executed.
So you don't really have a user-managed cursor in this system, ever. You
have only a message that was retrieved via a (possibly destructive) GET.
The "cursor" is only your ability to decide whether you will accept a newer
or higher priority messages on the next GET.
-- T.Rob
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
