I have the call to the module in a block already.

It goes something like:

package eCarList::Admin;
use eCarList:B;
use eCarList::Output;

use vars qw($db);

sub handler {
my $r = shift;

$db = eCarList:B->new();

....
}

On 10/11/06, Tyler Bird 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:BI->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:BI->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:BI. 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:BI. 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:BI 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;
> > }
> >

>
>