Oracle Advanced Queueing Experiences

Question

I am considering to use the Oracle Advanced Queueing technology for asynchronous communication. My aim is to use it for concurrent process execution (asynchronous PL/SQL procedure calls).

The current legacy implementation for the concurrent process execution is made of Unix KornShell (ksh) scripts which we are starting from front end via SSH connection in background mode. It works fine for us, but I am unhappy with that kind of solution because of:

• Security (front end starts a SSH connection and executes ksh scripts in background mode. From our colleagues I noticed that this kind of login will be restricted in our company.)
• Maintenance (Not everyone of our team is familiar with ksh scripts)
• Diversity in technology (I try to decrease the diversity in technology because of know how and migration efforts)
• Logging (Our back end system logs into database log tables, the concurrent execution logs partially into a log file)

By moving from ksh to the database I will be able to increase overall quality of my system:

• Security (No SSH connections anymore, the front end will send messages to the database and the database message listener will react to the messages and execute procedures asynchronously)
• Maintenance (We use PL/SQL, where we are familiar in)
• Diversity in technology (By next OS migration we will need to migrate only the database objects and the data)
• Logging (We will fully use our back end logging solution)

What do you think about my considerations and what are your experiences with Oracle Advanced Queueing? Especially in stability, performance and maintenance? Are there better alternatives?

Answer 1

The management of flows with Asynchronous queues Oracle brings with it advantages and disadvantages:

ADVANTAGES

1. Ability to manage flows by type creating ad hoc code on which to create Handler (JOB EVENT or APPLY PROCESS) to manage the various Sub Flows
2. Easy to put out a whole type of flows closing DEQUEUE Queue.
3. Managing Priorities (Parameter in the creation of Coda) of MSG for INSERT TIME or PRIORITY (msg parameter in the Payload) Managing message with a deadline or an Elapsed TIME.
4. Align the paradigm to a solution to EVENT no POLLING

DISADVANTAGES

1. The load of Business Logic will all be on the DB.
2. When Installing New PKG you will need to stop the queues (queuing and DEQUEUEING) to restart the HANDLER that point to the PKG.
3. Having to implement a recovery system msg Incorrectly Processed.

I think a good solution would be to use the CODE JMS (JMS provider) on the tails ORACLE so as to move the BL on JAVA and to use the various potentials of the language including the Logging.

Answer 2

I obviously don't know the details of your project, but if asynchronous PL/SQL procedure calls is your only goal, it may be easier to use DBMS_SCHEDULER. Your program could submit jobs to "run now" through the scheduler that call your PL/SQL. In my opinion, the scheduler is a much easier thing to work with than AQs.