Re: Pro*C Question: Forking Processes

Frank-Michael Zimmer wrote:
>
> Well, thanks a lot for the comments and suggestions - I think I should
> specify my problem a bit more:
>
> The program is written in Pro*C and runs on Solaris, with Oracle version
> 7.1.4.
>
> The idea is of something like a demon that wait at the lower end of a
> pipe to accept orders. The orders are inserted into the upper pipe end
> by routines from a package that resides in the database. If you have an
> order, just call the package procedure, it will turn it into a message,
> throw that down the pipeline, and the 'demon' will take care of its
> execution.
>
> To execute the order, the 'demon' has to spawn a child, for the orders
> might take long to execute (fetch (large!) datasets from the database
> and write them to a directory - the data may well be migrated into a
> unitree system), and doing the work himself will block him for too long.
>
> Also, the 'demon' is expected to deliver some kind of receipt upon
> completion of his task. The method implemented calls another package
> function. The important point is just that whoever writes the receipt
> has to be connected to Oracle.
>
> The _real_ problems ;) now are:
>
> 1) Who writes the receipt, and when?
> Forking while connected means that Oracle sees the last of the two
> processes that used the database connection as the legitimate owner.
> Usually, the son writes his receipt and terminates, thereby killing the
> father's connection, too.
> On the other hand, if the son does not use his connection but hands his
> data to the father to write the receipt and simply terminates
> afterwards, the connection is ok, but the father has to keep track of an
> undetermined number of children. I did this by having the father use a
> list of his sons' data, with the effect that a very quickly terminating
> son will cause the father to remove his son from the list before he has
> entered him into it! So this does not work, either.
>
> 2) To disconnect, or not to disconnect?
> Disconnecting, forking and then connecting again so each of the two
> processes had his own session is a good idea for a solution, but there
> have been problems in the praxis: After the sons terminate, the father
> receives a SIGCHLD signal to inform him that there may be a data
> heirloom for him, to be collected by the system call wait(). The first
> dead child is removed all right, but any further children that die
> suffer the grisly fate of a unix zombie... ;) This happens
> independently of the actual actions the children take with Oracle. I
> suspect that there is a problem with the father's waiting at the pipe
> for a message to pop out (a blocking procedure call) being interrupted
> by the SIGCHLD signal and entering the signal handler.
> As this mechanism works well when Oracle is not involved, I doubt that
> it's simply a unix problem.
>
> Ah, well. If you have read this far, I thank you for your patience and
> would appreciate your thoughts on the subject, just like any ideas or
> suggestions.
>
> Have a nice weekend,
>
> Frank-Michael :D

Frank,

I have a similar (same???) problem.

Oracle 7.2.3 on Solaris 2.5

From a Pro*C code if I get an oracle error, I do a connect to oracle again. When this happens, the child (oracle shadow process) becomes defunct (ps -ef shows this info). If I do n connects then there are n defunct child processess. These defunct process die only when the parent dies. Contacted Oracle support. They said that this is a BUG in 7.2.3. They said the problem is with the SQL*NET V2 bequeath pipe driver.

They suggested the following workarounds.

1. To include the signal(SIGCHLD,SIG_IGN) before connecting -- this does not work. On solaris SIGCHLD is ignored by default (check man -s 5 signal).
2. Set the TWO_TASK variable to P: (this uses the SQL*NET V1 pipe adapter) -- This WORKS.

I still don't know if setting the TWO_TASK=P: has any performance impact. What is the difference between the SQL*NET V2 bequeath pipe adapter and SQL*NET V1 pipe adapter?

I can mail you the info about this BUG if you need it.

ANY SUGGESTIONS. Thanks a lot for any help. Please email also.

Naren Chintala
naren_at_mink.att.com
nchintala_at_mink.att.com Received on Sat Aug 31 1996 - 00:00:00 CEST