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();
[download]

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.