> From: Josh Danziger
> You misunderstood my original statement. I was suggesting that the
> $dbh->ping() call be put in the cgiapp_init() block or an equivalent
I think that the ping step in the init block can be skipped since the
connect_cached method does that for you
Dan
-
From: Cees Hek <[EMAIL PROTECTED]>
>
>That seems like lots more code for something that you already
acknowledge rarely happens. Seems like more room for error to me...
It's just a common routine. The code that's executed after every DBH funcion is
simply "if ($@)". If the common routine is call
On 10/31/05, Mark A. Fuller <[EMAIL PROTECTED]> wrote:
> I never liked the approach of pinging the DBH *before every* access. Since the
By every access, do you mean every query, or every page request? I
don't think it is that unreasonable to do a ping when you first ask
for a cached database hand
From: Michael Peters <[EMAIL PROTECTED]>
>The question really comes down to, is the overhead of ping()
greater than the overhead of an eval{} (or worse if you use something else).
I've assumed that you always need an eval -- that ping only tests the
connection, not the execution. Seems like I've
Mark A. Fuller wrote:
> From: Josh Danziger <[EMAIL PROTECTED]>
>
>>You misunderstood my original statement. I was suggesting that the
>
> $dbh->ping() call be put in the cgiapp_init() block or an equivalent, and
> run once per execution of the PAGE, not before very DBI call!
>
> The same p
From: Josh Danziger <[EMAIL PROTECTED]>
>You misunderstood my original statement. I was suggesting that the
$dbh->ping() call be put in the cgiapp_init() block or an equivalent, and
run once per execution of the PAGE, not before very DBI call!
The same principle isn't it? Why test for a success
[mailto:[EMAIL PROTECTED]
Sent: Monday, October 31, 2005 9:48 AM
To: Josh Danziger; 'Sven Neuhaus'; cgiapp@lists.erlbaum.net
Subject: RE: [cgiapp] CAP::DBH + FastCGI: persistent DB connections, please
I never liked the approach of pinging the DBH *before every* access. Since
the occas
From: Josh Danziger <[EMAIL PROTECTED]>
>
>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 dat
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, p
Sven Neuhaus wrote:
> Hello,
>
> when using CGI::Application::Plugin::DBH with FastCGI (or mod_perl), are
> the database connections persistent?
Just to mention, persistent connections are a piece of cake under
mod_perl. You just 'use Apache::DBI' before you use anything that might
need a data
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 u
11 matches
Mail list logo
