in reply to CGI behavior/handling, and DBI

No, I am not running mod_perl, this is just a normal CGI script. Which leads me to believe that all database connections should die becuase the destroy method gets called on the database handle when the script exits, regardless of whether you explicitly call $dbh->disconnect(), right?

Replies are listed 'Best First'.
RE: Re: CGI behavior/handling
by lhoward (Vicar) on Jul 20, 2000 at 00:36 UTC
    Depending on your database server the statment handles may still be open (or at least using resources in the RDBMS) even after you close your database handle. Make sure you have an $sth->finish() for each of your statment handles (if you want to be really paranoid, undef them after you finish them). Try running your script (or a slimmed-down version of it) from the command line and using the trace command ($dbh->trace(1)) and examine the output.
      Thanks. I'm still not certain which of 2 scripts caused the problem, but I did forget to call $sth->finish() in one of them. I enabled $dbh->trace(1) (and then 2 :) and couldn't find anything wrong. Hopefully it works now.

      This brings another question to mind: under the right (or wrong...) conditions, I might have a SQL query that hangs for a long time. Supposedly, the webserver has a cron job that kills CGI processes after 15 minutes of execution. Is it possible that whatever signal this cron job sends could cause Perl to exit without calling the destroy method on the database handle?

        If your cgi script dies hard (segmentation fault, etc...) it will not close the database handle. Some DBMS's are tolerant of this, some are not. Any sort of relatively normal death of your .cgi program will cause the DBH disconnect to happen. This sourt of behavior is very hard to cause externally (such as by a kill -9) but depending on your DBD driver it could happen.