in reply to mod_perl, Apache::Session

Hmm... I will confess that I don't know much about mod_perl or Apache::Session, but I'll speculate a little since no one has replied to this yet.

First, I notice that you are not checking your return codes on your SQL. For example:

$sth->execute($login, $passwd) or die $dbh->errstr;
If your SQL is not executing, this should give you some clues. Also, are you checking the return codes on your connect and disconnects?
$dbh = DBI->connect($data_source, $user, $password) or die $DBI::errst +r;
Or, you can use RaiseError to avoid checking the return value of each call:
$dbh = DBI->connect($data_source, $user, $password, { RaiseError => 1});
Note that failure to connect or disconnect returns undef and sets $DBI::err and $DBI::errstr. Do not bother checking $! as it will not be set. I've never tried to execute SQL against a database that I have not successfully connected to, so I am curious if that may cause problems.

Second, are you properly disconnecting from the database? I believe, like open files, that mod_perl will choke if you forget to close a database handle and then try to reopen it.

Here's another bug that has bitten me: I have written code that connects or disconnects from databases based upon conditionals. As a result, I have sometimes had (shame on me) a close get skipped because I wrote my conditionals poorly.

Are you locking the table and forgetting to unlock it? Perhaps your code is waiting for a table to unlock? And are you accessing locked and unlocked tables at the same time? Here an annoying little snippet from the book "MySQL & mSQL":

Incidentally, newer versions of MySQL do not have this problem.

I know most of this is probably irrelevant, but hopefully there may be a useful nugget or two.

Cheers,
Ovid

Replies are listed 'Best First'.
RE: Re: mod_perl, Apache::Session
by le (Friar) on Jul 10, 2000 at 01:48 UTC
    RaiseError is set, so I don't think I have to bother with additional error checking.

    I believe I don't have to care about database handles, since you can pre-connect to a database and server startup, and the database connection stays the same anyway. Hmm.

    And yes, it was indeed a locking issue, but see my other post on that.