Re^5: Ignoring/Trapping the DIE signal

Yeah, the performance cost is why I only update the DB after a successful send, and then only with basic info, not all the different pkt type counts.

You could consider using a shared memory segment or mmap'd file for this sort of information; they're very fast, but the OS can provide persistence even if your process dies.

As for the eval{}, feel free to try it on the above code.

Well, the code below worked for me reliably over a few hundred connects...

#!/usr/bin/perl

use warnings;
use strict;

use DBI;


while(1) {
  eval {
    my $dbh = DBI->connect("DBI:mysql:database=test","blah","blah")
    or die "Couldn't connect to DB\n";
    my $sth = $dbh->prepare("SELECT * FROM sometable\n")
    or die "Couldn't prepare\n";
    $sth->execute()
    or die "Couldn't execute\n";
    my @row = $sth->fetchrow_array();
    $sth->finish;
  };
  if ($@) {
    warn "DB error: $@";
  }
}
[download]

--
sgifford's Web page

Comment on Re^5: Ignoring/Trapping the DIE signal Select or Download Code

Replies are listed 'Best First'.
Re^6: Ignoring/Trapping the DIE signal by chrism01 (Friar) on Jun 16, 2006 at 01:55 UTC
Thx for that; I tried a few eval combinations, but obviously missed something. (Don't think I've ever had to use evals in the past) Working on it now, as my actual code is more complex than my example OP. As I said, I was hoping to use a simple single die trap rather than lots eval{}s, but so long as it works I guess. Cheers Chris	[reply]
Re^7: Ignoring/Trapping the DIE signal by sgifford (Prior) on Jun 16, 2006 at 02:16 UTC
You generally don't need lots of `eval`'s; you should be able to put one big one around all of your code that accesses the databases. -- sgifford's Web page	[reply] [d/l]