[DB-SIG] Handling an open database connection after a fork?
mwm-keyword-dbsig.588a7d at mired.org
Sun Jan 13 20:07:09 CET 2008
On Sun, 13 Jan 2008 13:10:48 +0100 Dieter.Maurer at Haufe.de wrote:
> Mike Meyer wrote at 2008-1-11 11:35 -0500:
> > ... existing connection in forked children ...
> >So the question is - what should the child do to get a database
> >connection? Can it just keep using the existing db & cu variables?
> This is very unlikely.
That's what I expected.
> When the child is forked, it inherits the connections from the
> parent -- but the protocols usually do not expect that several
> processes (parent and child) are using them asynchronously.
Right. The question is, what's the right way to handle the connection
on the child side of things?
> >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
> 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. 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. I'm willing to believe that
should work. So how do I simulate what happens on exec without
actually doing the exec?
Mike Meyer <mwm at mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
More information about the DB-SIG