I have the call to the module in a block already.
It goes something like:
package eCarList::Admin;
use eCarList::DB;
use eCarList::Output;
use vars qw($db);
sub handler {
my $r = shift;
$db = eCarList::DB->new();
....
}
On 10/11/06, Tyler Bird <[EMAIL PROTECTED]> wrote:
Try wrapping your calls to your module in a function because an object
is cleaned up at the end of a block.
-- yourscript.pl --
sub main()
{
my $db = Apache::DBI->new();
} # at the end the object refrenced by $apache_dbi will have it's
destroy method called
I think you have have done somehting like this
#!/usr/bin/perl
my $db = Apache::DBI->new()
In that case I don't think it's ever destroyed.
but other thoughts I have are that whenever you use mod_perl with
apache::dbi it uses persistent database connections
and does not close them when you call disconnect.
But I know you should be able to write it to get the destructor to be called
Jordan McLain wrote:
> I have written a handler that calls a constructor to a module that I
> have written. I do not believe that the subsequent destructor is
> being called unless I explicitly call it. Is this a feature of
> mod_perl? I would think that every time an instance of the module is
> created, it would be destroyed properly when using mod_perl.
>
> The reason I am doing this, is that I am testing to see if I want to
> continue using Apache::DBI. I have 4 databases that need to be
> connected to, and I end up having alot of MySQL threads hanging out if
> I use Apache::DBI. The problem comes in that I have all disconnects
> in the DESTROY method for the module(all of my database interaction is
> abstracted using an OO module) and I end up having no difference
> between Apache::DBI and using only DBI (threads stay persistent)
> unless I call destroy explicitly from the handler ( $db->DESTROY ).
>
> sub DESTROY {
> my $self = shift;
>
> $self->dbh->disconnect() if defined $self->dbh;
> }
>
