DBMS_JOB and 'near' real-time

All,

I've designed and implemented a phone integration system that accepts caller information on the CTI server and then calls a stored procedure to keep track of the caller information. The stored procedure calls DBMS_JOB.SUBMIT to pre-build customer account data. The voice port is freed up for the next caller and the current caller is put into a queue on the phone switch. Eventually, a customer service rep requests the call, the customer account data is screen popped to the CSR and the phone call is transferred from the switch to the handset. Sometimes, the caller information can return multiple potential customers (no more than 5) and a DBMS_JOB.SUBMIT is spawned asynchronously for each potential match to pre-build the customer account data.

So far this architecture using DBMS_JOB.SUBMIT is working great!

An alternative architecture is to return a customer id result set to the CTI server which would then spawn the required number of threads that would call the customer account build stored procedure.

The reason that I went with the DBMS_JOB method is that the CTI server has already called a stored procedure and that SP has figured out the customer id result set and simply fires off as many DBMS_JOB's that are in the result set.

Returning a customer id result set to the CTI server would require the CTI server to spawn threads that would then connect to the database and invoke the customer account build stored procedure. Network latency could become a factor.

It seems to me that using DBMS_JOB in this way saves on network roundtrips as well as database connect time that would be required by the CTI server spawning threads.

Feedback regarding this architecture and alternatives is more than welcome.

TIA, Matt Received on Thu Jan 12 2006 - 22:20:29 CST