In general, you can't use a DBH across a fork. I don't know of any db clients where the handle will survive a fork.

You write, however,

it appears that all the children end up sharing the same DBH

The good way to check would be to have your program fork, let each child open a connection, then sleep for a minute or something. During that time, log on to the database using another tool (Toad or DB-Artisan or something) and see how many connections are in your name. If the numbers agree, you're done.

...or, you could have each child just print the database handle. Like all perl objects, it's just a reference, so it should print something like DBI::db=HASH(0x1223456). If they all print the same reference, done. No monkeying around on the database at all (well, except the DBI calls that is...but you already knew that :P).

thor

Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come

Actually, that's incorrect, and it's probably the same mistake that the original poster made. The flaw is that the memory address shown as part of the stringification of the reference is the *relative* memory address to that process. The operating system uses something called "virtual memory", which abstracts the actual *physical* memory location away from your processes. In truth, the physical memory addresses may change from time to time, as your process is swapped and paged and so on.

Anyway, here's a quick demo:

prompt> perl -le 'my $pid = fork; my $x = [$pid]; print "$x->[0] -- $x
+"'
0 -- ARRAY(0x80d11ec)
24694 -- ARRAY(0x80d11ec)
prompt>
[download]

You can see that each process has it's own array, with the reference stored in $x, yet in both processes, the memory address appears the same.

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

Either let each child have its own connection, or have a common process (eg the 'mother') handle all the database traffic, and use something else to communicate with this 'db-server-process', some sort of RPC or shared memory or... YMMV.

Just don't (repeat DON'T) share database connections between processes.

Did I remember to say that you should not share connections between processes?

Either let each child have its own connection, or have a common process (eg the 'mother') handle all the database traffic, and use something else to communicate with this 'db-server-process', some sort of RPC or shared memory or... YMMV.

Okay, I'm having the same error and I'm getting the same with every other thread after the first thread finishes. Any thoughts? I'm doing just that myself; Global dbh in $this->{'dbh'} and each child defines it's own $this->{'_dbh-child'}. As soon as I call the first $this->{'_dbh-child'}->disconnect(), every other disconnect fails or spews out that error above, including the master {'dbh'}.

-- philip
We put the 'K' in kwality!

The above can be omitted. Turns out the children where closing out the Global DBI object every time they where closing themselves out. It was causing the error. Moving the Global DBI call to a localized method fixed it right up.

-- philip
We put the 'K' in kwality!