in reply to The pain of DBI !!! Lost connection from forked or threaded children

Note what the DBI documentation has to say about InactiveDestroy (emphasis mine):

This attribute is specifically designed for use in Unix applications that "fork" child processes. Either the parent or the child process, but not both, should set InactiveDestroy true on all their shared handles. (Note that some databases, including Oracle, don't support passing a database connection across a fork.)

You do set InavtiveDestroy unconditionally. Also, you don't show where you call fork() and you don't tell us what database you use. I think that properly using InactiveDestroy, as per the documentation, should fix this problem, but if you continue having problems, a small, self-contained example will likely elicit better answers than mine.

Replies are listed 'Best First'.
Re^2: The pain of DBI !!! Lost connection from forked or threaded children
by expresspotato (Beadle) on Dec 28, 2009 at 16:03 UTC
    Hi, Thank you for your prompt reply. Wouldn't constantly creating new handles through
    $z1++ @dbh1[$z1]->DBI:...
    Make them independent from each other? I'm just uncertain why DBI would trash another connection from a completely different thread or fork even when the DBH isn't the same. I will try setting InactiveDestroy just in the child processes and post back in an hour.

      First of all, you're not creating new connections there, because you're using connect_cached, which will try to reuse an existing connection. Second, even though you might be getting separate Perl objects, your database driver may or may not understand how to handle a fork situation. This is mainly an issue within the database driver (DBD), which likely is written in C and thus needs to take special care when fork()-ing or using multiple threads.

      So far, you haven't shown any code relevant to fork(), and you haven't told us the platform you're running on, nor have you told us which database/driver you're using. There may still be many more interesting problems lurking, for example if you're on Windows, where the fork system call is emulated through threads. But telling us these details would possibly cut short the chase, so don't spoil the fun.

        The OP appears to be using MySQL, as in:
        $connectionInfo="dbi:mysql:$db;$host";
        but I can't see where the fork or threading is done.