Re: [cgiapp] CAP::DBH + FastCGI: persistent DB connections, please

[Michael Peters <suppressed>]

Josh Danziger wrote:
> There's a good way and a bad way.
> 
> First, the bad way.  For generic, run-of-the-mill persistent variables, a
> package level variable will do the trick.  C::A and "my" variables will be
> destroyed by the garbage collector when the script is done executing.
> However, package level variables are around until the package is unloaded
> (around when END blocks are executed)

I hate to be picky here, but 'my' variables won't necessarily be cleaned
up at the end of a request. 'my' variables are only cleaned up when
their scope expires. If they are declared at the file scope, then they
last just as long as 'our' variables do.

> Here's an example...
> 
> ####################################################
> package MyCgiApp ;
> use base 'CGI::Application' ;
> 
> use DBI ;
> 
> our $persistent_var = 0 ; # persistent


You could just as easily have used 'my' there. The only difference is
that by using 'our' you make the variable visible from the outside. So
if you'd like to be able to do this:

  $MyCGIApp::persistent_var

>From outside of the package MyCGIApp, then you need 'our'. Else 'my'
works just fine and would make the variable a file-scoped private.


> Here's the problem with this for an SQL connection...  Many bargain basement
> web hosts will have SQL connections automatically die with an extremely
> short timeout period.  If this is the case, then the connection might die in
> between one execution and the next.  Therefore, it is important to check
> that the database is alive before actually using it.  For example, using the
> $dbh->ping() method.

Which is why Apache::DBI is so nice under mod_perl, since it will do all
the ping() stuff for you.

> This, of course, is a royal pain in the kicker, and so we have much better
> methods for you to use.
> 
> The DBI package has a built in function call for pooled database
> connections.  Simply calling DBI->connect_cached(...) instead of
> DBI->connect(...) with the same exact parameters will get the cached 
> DBI->copy if
> (a) it exists and (b) it is still alive.  This would be preferred for
> obvious reasons.

Another picky point: connection pooling and persistant connections are 2
completely different things. Connection pooling involves sharing a group
of db connection between multiple processes and is quite complicated.
Persistant connections means that each process keeps a (or multiple)
separate, open connection to the database and only that process can use it.

-- 
Michael Peters
Developer
Plus Three, LP


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed