I'm trying to understand what's going on with some queues in a system i'm debugging. From the AQ$AVAIL_CHANGE_EVENT_QTAB view i'm seeing messages and some of them are being dequeued with a PROCESSED state and DEQ_TIME.
I don't see any dequeue call for this and no callback function, only a subscriber - a consumer.
Can someone help me understand how the dequeuing works ?
Here's what the DBA gave me :
BEGIN AQ.CREATE_PRIORITY_QUEUE(QTABLE => 'AVAIL_CHANGE_EVENT_QTAB', PAYLOAD_TYPE => 'AVAIL_CHANGE_EVENT_TYP', QNAME => 'AVAIL_CHANGE_EVENT_Q', MCONSUMERS => TRUE); END; BEGIN DBMS_AQADM.add_subscriber (queue_name => user||'.AVAIL_CHANGE_EVENT_Q', subscriber => SYS.aq$_agent ('farecache', NULL, NULL ) ); END;
using AQs you cannot "see" any dequeue call based on the AQ$ views, where the processed messages are logged.
You have an AQ "AVAIL_CHANGE_EVENT_Q" and a specified transportation mechanismen for enqueued messages.
This could be a scheduled job which permanently waits for new enqueued messages.
Depending on your specified subscribers these messages will be distributed to the targets.
Using the AQ$ views you can only see which messages have been processed in the past. Either your DBA or the developers
of the AQ source code know where you can find the corresponding AQ actions DBMS_AQ.ENQUEUE and DBMS_AQ.DEQUEUE.