Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: DBMS_JOB and 'near' real-time

Re: DBMS_JOB and 'near' real-time

From: Connor McDonald <connor_mcdonald_at_yahoo.com>
Date: Fri, 13 Jan 2006 20:13:51 +0800
Message-ID: <43C7997F.4E9@yahoo.com>


The House Dawg wrote:
>
> 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

Sounds to me like you may be using dbms_job as an alternative to dbms_aq, which may have more native queueing facilities for you

-- 
Connor McDonald
Co-author: "Mastering Oracle PL/SQL - Practical Solutions"
Co-author: "Oracle Insight - Tales of the OakTable"

web: http://www.oracledba.co.uk
web: http://www.oaktable.net
email: connor_mcdonald_at_yahoo.com


"Semper in excremento, sole profundum qui variat."

------------------------------------------------------------
Received on Fri Jan 13 2006 - 06:13:51 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US