[cgiapp] is my app caching db connection ?

[Mark Rajcok]

Thanks to the archives I found this thread related to persistent DB
connections when using CAP::DBH and FastCGI.   I changed my cgiapp_init()
code from:
   $self->dbh_config(

$self->config_param('dsn'),$self->config_param('user'),$self->config_param('password')
        ,{PrintError => 0, RaiseError => 0}
    );
to:
    $self->dbh_config(sub { DBI->connect_cached(

$self->config_param('dsn'),$self->config_param('user'),$self->config_param('password')
        ,{PrintError => 0, RaiseError => 0}
    ); });
and I now get persistent DB connections.  Very nice.

However, I would prefer if CAP:DBH did this automatically.  If I leave my
cgiapp_init() code as it was originally, and instead change DBH to use
connect_cached() instead of connect(), I also get persistent DB
connections.  In addition to FastCGI, connect_cached() works with plain CGI
and (according to the DBI documentation) with Apache::DBI.

Are there any reasons DBH should not be using connect_cached()?

BTW, I have a unit test script that uses Test::WWW::Mechanize to test my
CGI::App application and when I moved over to FastCGI, it ran 11 times
faster -- 12 seconds instead of 130.  I should have started to use FastCGI a
long time ago...

The CA wiki is still not editable.  Is anyone looking into fixing it?

On Mon, Jul 28, 2008 at 1:53 PM, Dan Horne <dan.horne at redbone.co.nz> wrote:
>
> I believe the way around this is to use the package variable approach Mark
> suggests with a C::A::P::DBH callback. DBI's connect_cached option, is
> designed to handle the stale connection problem (I use DBI directly, but the
> principle is the same):
>
>    # Use a callback to create your own handle that is still lazy loaded
>    $self->dbh_config(sub { DBI->connect_cached(); });