Dequeuing multiples messages in a PLSQL CallBack

Question

Hi all:
I would like to dequeue multiples messages in a PLSQL CallBack for performance reason.
Everything works fine, but I see that Oracle AQ sent the rest of the notifications messages to the callback independent of an empty queue.
I added a table lock to prevent parallel execution of the Call Back, but when this resource lock is freed, many oracle processes are started in parallel to process the rest of the notification pending.
Here my Call Back:
  static procedure msgCallBack(context  IN  RAW,
                               reginfo  IN  SYS.AQ$_REG_INFO,
                               descr    IN  SYS.AQ$_DESCRIPTOR,
                               payload  IN  RAW,
                               payloadl IN  NUMBER) is
    dequeue_options     dbms_aq.dequeue_options_t;
    message_properties  dbms_aq.message_properties_t;
    message_handle      RAW(16);
    message             lucene_msg_typ;
    prefix              VARCHAR2(4000) := utl_raw.cast_to_varchar2(context);
    rcount              NUMBER;
    begin
      EXECUTE IMMEDIATE 'LOCK TABLE '||prefix||'$T IN EXCLUSIVE MODE';
      EXECUTE IMMEDIATE 'select count(*) from '||prefix||'$QT' INTO rcount;
      if (rcount >0) then
        sync(prefix); -- dequeue all messages
      end if;
      commit;
  end msgCallBack;
sync(prefix) dequeues all messages pending on the queue, if statement is to avoid non-necessary call to sync procedure on an empty queue.
Is there any way to clean up all pending notification inside a Call Back?
I'll appreciate any help on this topic.
Best regards, Marcelo.

Answer 1

Hi Marcelo,
If you do a dequeue with dequeue_options.wait=dbms_aq.forever it will wait until the message is enqueued. It is not consuming (much) cpu-time. AQ solves this under water for you by polling the queue-table.
If you schedule this job with an interval of say 10secs (using dbms_job or dbms_scheduler) the job will come up after database startup. The only other option is to start the process using a sqlplus or similar tool. But since the dequeueu will wait for the next incomming message the sqlplus session will halt. Using the jobscheduler in the database causes the job to be run in a session with in the database (so you get your session freed) and after a database restart, the job will come up.
You can use this with a normal default queue. You should not use the dequeue_option visibility=dbms_aq.immediate, because then you loose your "transactional grouping".
I'd advise to either
. not use wait=dbms_aq.forever, but a reasonable amount of wait time and then let your job run to complete. Then the job scheduler can reschedule the process in an interval of for example 1 - 10 sec.
. do use wait=dbms_aq.forever but define a kind of "suicide pill". That is a message that you give a special meaning for example a correlation-id with a special text, and the highest possible priority. You have to make sure that it by passes every other message-priority. If the process gets this message it has to stop.
The reason I advise eiter of them is that you want a means of stopping the process in a neat fashion. For example for maintenance purposes. I personally have a slight prefrence for the first option, because when you remove the job from the jobscheduler you may trust that the job stops. For the second option you have to rely on the process receiving and consuming the suicide pill. But it is manner of taste: the second option is also a good way. The first option introduces a possible latency since the job is regularly not executing for a few seconds. The second gives the best response I think.
Regards,
Martien