Advanced Queuing - Oracle

Propagation Features
retry time is beyond the expiration time of the current window, the next retry is
attempted at the start time of the next window. A maximum of 16 retry attempts is
made, after which the schedule is automatically disabled. When a schedule is
disabled automatically due to failures, the relevant information is written into the
alert log.
A check for scheduling failures indicates:
How many successive failures were encountered
The error message indicating the cause for the failure
The time at which the last failure was encountered
By examining this information, a queue administrator can fix the failure and enable
the schedule. During a retry, if propagation is successful, the number of failures is
reset to 0.
Propagation has support built-in for Oracle Real Application Clusters and is
transparent to the user and the queue administrator. The job that handles
propagation is submitted to the same instance as the owner of the queue table
where the queue resides.
If there is a failure at an instance and the queue table that stores the queue is
migrated to a different instance, the propagation job is also migrated to the new
instance. This will minimize pinging between instances and thus offer better
performance. Propagation has been designed to handle any number of concurrent
schedules. Note that the number of job queue processes is limited to a maximum of
1000, and some of these may be used to handle nonpropagation-related jobs. Hence,
propagation has built-in support for multitasking and load balancing.
The propagation algorithms are designed such that multiple schedules can be
handled by a single snapshot (job_queue) process. The propagation load on a job_
queue process can be skewed based on the arrival rate of messages in the different
source queues.
If one process is overburdened with several active schedules while another is less
loaded with many passive schedules, propagation automatically re-distributes the
schedules so they are loaded uniformly.
Scenario
In the BooksOnLine example, the OE_bookedorders_que is a busy queue since
messages in it are propagated to different shipping sites. The following example
code illustrates the calls supported by enhanced propagation scheduling for error
checking and schedule monitoring.
A Sample Application Using AQ 8-115