It's the safest thing you can do without completely redesigning your code. The DBI and Oracle maintainers will appreciate hearing of any problems you have.

I always design to avoid conflicts like that, but old mistakes must be worked around.

Re: designing around it: true. Unfortunately, this code was originally for perl 5.5 (we only recently upgraded to 5.8), which didn't support weak referrences. Holding some sort of internal list of all the connected dbhs without weak referrences would have meant (indirectly) subverting the implicit disconnect when dbhs fall out of scope (which is generally a good thing). That would have been a bad thing.

As far as the fact that a fork can sort of corrupt various resources which aren't even used in the subprocess... well, that's unfortunate, but not isolated to DBI connections. A similar thing happens with IO buffers, necessitating that you do something like "flush all handles" before a fork. Unfortunately, this, too (at least used to be... someone may have fixed this since I last looked into it) has no good solution, as it requires the forking code to somehow reach out and grab a list of all of a process's resources of a type (in this case database handles, in that case buffered IO handles). Similarly, in apache, there's a necessary step of calling "cleanup_for_exec", so that child processes' sockets don't get selected for handling new requests. The list goes on, I'm sure... which is sad, because it means there's a whole laundry list of things you need to remember to do if you want to fork... forgetting to do any of them meaning a potential obscure bug.

------------
:Wq
Not an editor command: Wq
[download]

As far as the fact that a fork can sort of corrupt various resources which aren't even used in the subprocess... well, that's unfortunate, but not isolated to DBI connections.

Exactly. To be really careful, a program which forks should avoid letting the kids inherit such connections.

After Compline,
Zaxo

A few months ago, to make a point about some of the pitfalls of fork and IO, I wrote a few tests to show the potential problems (from a Un*x perspective following the R. Stevens books for instance), and all my tests were negative in the sense that (at least on cygwin -- I think I tested HP-UX which has been my perl platform for years, but I cannot remember for sure) implicit flushing was going on ...It would be interesting to know how much perl departs from Un*x on this (and since when).

In general for this kind of problem, maybe the best way to go is a process manager maintaining a pool of processes each one with one DB connection, and some protocol to reach the process manager. Anyway I find the "forks" module interesting.

cheers --stephan

It's not clear from your writeup, so I'll mention it anyway. After the fork, even if you set InactiveDestroy, it's important that the child not use the database handle. Basically, after setting InactiveDestroy, you should then destroy it. I wrote about this in DBI, fork, and clone..

As to your question, my reading of the documentation is that the array itself should not be modified. That is, you should not try to add a handle to it or splice one out or anything. What you're doing should be fine.

Hello,

Looks like there is a typo (that wreaked havoc on my code !)

Ought to be:

sub MakeAllDBHsForkSafe {
    my %drivers = DBI->installed_drivers;
    foreach my $drh (values %drivers) {
        map { $_->{InactiveDestroy} = 1 } @{$drh->{ChildHandles}};
    }
}
[download]

Instead of:

sub MakeAllDBHsForkSafe {
    my %drivers = DBI->installed_drivers;
    foreach my $drh (values %drivers) {
        map { $_->{InactiveDestroy} = 1 } @{$_->{ChildHandles}};
    }
}
[download]

Then, I would go for some code a bit more cautious :

sub MakeAllDBHsForkSafe {
    my %drivers = DBI->installed_drivers;
    foreach my $drh (values %drivers) {
      $_->{InactiveDestroy} = 1 for (grep {defined} @{$drh->{ChildHand
+les}});
    }
}
[download]