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.
In reply to Re: Re: forking and dbi
by djantzen
in thread forking and dbi
by dlspinhir
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |