Re^2: CGI::Session + DBD::SQLite = closing dbh with active statement handles

in reply to Re: CGI::Session + DBD::SQLite = closing dbh with active statement handles
in thread CGI::Session + DBD::SQLite = closing dbh with active statement handles

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

Comment on Re^2: CGI::Session + DBD::SQLite = closing dbh with active statement handles Select or Download Code

Replies are listed 'Best First'.
Re^3: CGI::Session + DBD::SQLite = closing dbh with active statement handles by bash (Scribe) on Feb 05, 2008 at 05:06 UTC
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".	[reply]

Replies are listed 'Best First'.

Re^3: CGI::Session + DBD::SQLite = closing dbh with active statement handles
by bash (Scribe) on Feb 05, 2008 at 05:06 UTC

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".

[reply]

In Section Seekers of Perl Wisdom