[DB-SIG] Handling an open database connection after a fork?

[Dieter Maurer]

Mike Meyer wrote at 2008-1-13 14:07 -0500:
> ...
>On Sun, 13 Jan 2008 13:10:48 +0100 Dieter.Maurer at Haufe.de wrote:
> ...
>> >If
>> >not, does it need to do anything special, or avoid doing anything, in
>> >order to not disrupt the parent processes use of those variables?
>> Open a new connection in your forked child.
>
>Obvious. What do I do with the old one? I started out by explicitly
>closing it, but that seems to make oracle unhappy (internal errors of
>various kinds).

Your best bet is to leave it alone.

If you are lucky (!) then this will be sufficient.
As I mentioned, for a ZODB it was not sufficient --
because the child intercepted
messages destined for the parent and eat them away.

If you face similar problems, give up and "exec" in the forked
process.

>> I finally abondoned this approach completely (because, LDAP
>> was used deeply in my system and I had no control over the creation
>> of new connections) and am now using "fork+exec".
>
>Oddly enough, fork+exec doesn't make the problem go away, just
>provides another possible solution.

Maybe, you state precisely what problem you have.

Usually, it is not a problem that the execed child has some
open fds that it does not need.

When it is, you can explicitely close all connections, e.g.
before you exec.

>Open fd's can either be closed on
>exec, or not. Hopefully, it's closed because the python objects that
>referred to it are lost across the exec.

No, they remain open (as the complete memory state is replaces --
there is no way, Python can intercept the "exec").

>I'm willing to believe that
>should work. So how do I simulate what happens on exec without
>actually doing the exec?

You do the "exec" -- you cannot similate it (unless you are
using deep and very low level system magic, not directly supported by
Python).



-- 
Dieter