Re: Pipe Problems

A copy of this was sent to Michelle Warner <hrdbdy_at_sprynet.com> (if that email address didn't require changing) On Thu, 12 Nov 1998 06:43:11 -0500, you wrote:

>I am using a ProC daemon to communicate between an application running
>on the Oracle Web Application Server and shell scripts. The scripts are
>launched by the ProC daemon executing a system command. The daemon is
>made up of a listener and sql_processor modules. The listener process
>listens on the pipe and when a message is received the first item is
>unpacked and placed in a global variable and then a fork is performed
>and the sql_processor module is called by the child. The
>parent/listener goes back to listening on the pipe. The child unpacks
>the remaining items on the pipe, does some processing and then returns
>information, a status on a return pipe to the web application. But it
>appears the web application never receives the status. When I remove
>the fork every thing appears to work fine. Anyone have any ideas?
>
>Should the listener unpack the entire pipe before forking the child
>since the listener goes back to listening on the same pipe?
>
>Thanks in advance.

Using fork() with a connected pro*c program is a very bad idea (especially if fork is not immediately followed by exec in the child process).

Each process needs it's own connect to the database. The child process is 'inheriting' the parents database connection. The child and parent CANNOT share this connection. the child must establish its own connection but this is hard since it believes that it is already connected.

If a pro*c program forks, it had better EXEC right after that else it simply will not work. You need to reconnect in the child process.

Another, more optimal perhaps, solution is to start a 'pool' of these daemon processes (eg: have 5 pro*c programs -- identical programs -- up and running at all times). The dbms_pipe package will ensure that a packed message will only be recieved by one of these processes. If you start 5 identical processes, you'll be able to run upto 5 scripts concurrently and dbms_pipe will queue the reamining requests (so when one of the processes goes back to read on the pipe, a message might already be there waiting on the queue).  

Thomas Kyte
tkyte_at_us.oracle.com
Oracle Government
Herndon VA

--
http://govt.us.oracle.com/    -- downloadable utilities
 
----------------------------------------------------------------------------
Opinions are mine and do not necessarily reflect those of Oracle Corporation
 
Anti-Anti Spam Msg: if you want an answer emailed to you, 
you have to make it easy to get email to you.  Any bounced
email will be treated the same way i treat SPAM-- I delete it.