Right. Here's a bit of code I used recently to explore these issues. It uses (the very nice) Parallel::ForkManager, although the fundamentals are the same for normal forking. Since each handle lives in its own process, transactions are unique to each one, which is a boon for efficiency and makes it safe to have multiple users writing to the DB:
#!/usr/bin/perl
use strict;
use warnings;
use Parallel::ForkManager;
use constant NUM => shift; # number of children to spawn.
my $pfm = new Parallel::ForkManager(NUM);
my $id = 0; # a unique id for each process
# a sub to be run *from within the parent thread* at child creation.
my $init = sub {
my ($pid, $ident) = @_;
print "++ $ident started, pid: $pid\n";
};
# a sub to be run *from within the parent thread* at child termination
+.
my $finalize = sub {
my ($pid, $exit_code, $ident) = @_;
print "-- $ident finalized, pid: $pid\n";
};
# set the subrefs
$pfm->run_on_start($init);
$pfm->run_on_finish($finalize);
# now for the fun bit.
for(1..NUM) {
# spawn a new process and break to begin the next iteration, as each
+
# child process will continue the loop but the parent should not.
my $pid = $pfm->start(++$id) and next;
$main::db = DBI->connect( ... ); # use your specific initializatio
+n args
# Do your stuff, sit in a loop to service requests, etc.
$main::db->commit(); # or rollback, or something depending on condit
+ions.
$main::db->disconnect();
$pfm->finish(); # exterminate! exterminate!
}
# make sure we don't leave any zombies roaming about.
$pfm->wait_all_children();
Now if you're running 5.8, you may have the option of sharing the database handle between threads, although I haven't been able to test this yet. Probably though you'd want to take advantage of the stringent separation of data between threads so you'd have similar behavior as when forking.
|