Basically, what the "active statement handle" warning means is that the database connection is going away while there's a query still active which might have results which haven't been retrieved yet. Some database drivers are smart enough to recognize that a query has had all results retrieved when the last row is fetched. Others don't recognize this until you attempt to fetch a row that isn't there. You are apparently either using one which falls into the latter category (more likely) or the session table has gotten messed up such that the id you're testing with has multiple a_session records.

The reason that switching to prepare would fix this is that it allows $sth to be destroyed when it falls out of scope at the end of the sub. prepare_cached stores a second copy of the statement handle in case that same query is prepared again later; it is this second (cached) copy which is still active when your database connection goes away and triggers the warning.

A better solution, IMO, would be to continue using prepare_cached and add the line $sth->finish; immediately after my ($row) = $sth->fetchrow_array();. This will tell the database engine that you're done with the query's results even if it thinks there may still be additional rows to return.

Database does not contain duplicated records, so fetchrow_array() returns all data. Here is my test-case program for current situation:

#!/usr/bin/perl -w

use strict;
use DBI;
use Data::Dumper;
use Storable;
use warnings;

sub get_session {
    my ($dbh) = shift;
    #$dbh->{TraceLevel} = 2;
    my $sid = $ARGV[0];
    my $SQL = sprintf("select a_session from sessions where id = %s", 
+$dbh->quote($sid));
    my $sth = $dbh->prepare_cached($SQL, undef, 3);
    $sth->execute;
    my ($val) = $sth->fetchrow_array;
    #[1] my ($val2) = $sth->fetchrow_array;
    #[2] $sth->finish;
    my $session = Storable::thaw($val);
}


my $dbh = DBI->connect('dbi:SQLite:dbname=db/sessions.db');
print Dumper(get_session($dbh));
$dbh->disconnect;
[download]

If we run program as it looks, result will be:

DBI::db=HASH(0x87a79c)->disconnect invalidates 1 active statement hand
+le (either destroy statement handles or call finish on them before di
+sconnecting) at ./decode_sessions.pl line 26.
closing dbh with active statement handles at ./decode_sessions.pl line
+ 26.
[download]

If I uncomment (1), (2) or (1)+(2) result:

closing dbh with active statement handles at ./decode_sessions.pl line
+ 26.
[download]

PS. I have found that something like this already in CPAN bug list: http://rt.cpan.org/Public/Bug/Display.html?id=31239

I think i found solution. The problem is that DBD::SQlite->disconnect() method execute sqlite3_close() function. This function return SQLITE_BUSY in case if there are any active statement. From API: "Applications should finalize all prepared statements and close all BLOBs associated with the sqlite3 object prior to attempting to close the sqlite3 object." Currently DBD::SQLite can finalize statements only via DESTROY method. In simplest case you can always use "undef $sth" or wait untill it goes out of scope which will finalize statement. But if you prepared statement via cache (prepare_cached) it will not work for you, because statement is till inside DBI cache. In this case we can call DESTROY on our cached statement only via DESTROY for database handler. And we can achieve it by "undef $dbh". "undef $dbh" - will close all cached statements and close database without any errors. Conclusion: avoid using $dbh->disconnect() for DBD::SQLite, instead use "undef $dbh".

sub DESTROY {
    my $self = shift;

    unless ( $self->{Handle}->{AutoCommit} ) {
        $self->{Handle}->commit;
    }
    if ( $self->{_disconnect} ) {
        undef $self->{Handle};
    }
}
[download]

I'm a CGI::Session maintainer. Is the expectation that this bug has always been there in the driver, or that something changed in a newer version of DBD::SQLite which causes it?

I'm trying to determine if the proposed fix would be backwards compatible.

I don't know exactly. At one my server I can't reproduce it. But many people says that DBD::SQLite has spewed this warning for as long as they can remember.