Yes, the time interval is small, which is why Time::HiRes catches it and the
default perl time method does not. While, to be fair, the likelyhood of
this happening is perhaps not worth the effort, I was just pointing out that
the Apache::DBI documentation:
"Setting the timeout to 0 will always validate the database
connection using the ping method (default)."
while not exactly true with Apache::DBI as is. It was, however, the
functionality I was after.
Perhaps requiring the Time::HiRes module is not the most effective solution
(if you agree it's a problem :)
I think changing line 103 of Apache/DBI. to:
my $needping = ($PingTimeOut{$dsn} == 0 or $PingTimeOut{$dsn} > 0 and $now
- $LastPingTime{$dsn} > $PingTimeOut{$dsn}) ? 1 : 0;
also seems to have the desired effect.
--Geoff
> -----Original Message-----
> From: Edmund Mergl [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 01, 2000 4:01 AM
> To: Geoffrey Young
> Subject: Re: Apache::DBI time bug?
>
>
> Geoffrey Young wrote:
> >
> > Just something minor...
> >
> > I use DBI for both content and log handlers. When using
> debug level 2 I
> > noticed that the the default perl time method is not
> precise enough between
> > request phases - that if I could not connect in the
> PerlHandler phase,
> > Apache::DBI did not ping the database for the PerlLogHandler phase.
> >
> > Adding:
> >
> > use Time::HiRes qw(time);
> >
> > to the top of DBI.pm seemed to fix the problem.
> >
> > probably no big deal for most, but just wanted to point it out...
> >
> > --Geoff
>
>
>
> so this problem comes up if the database is present during the
> PerlHandler phase and it is not available if it comes to the
> PerlLogHandler phase. Isn't that a very small time intervall,
> so tht the probability that this happens is negligible small ?
>
> Edmund
>
>
>
> --
> Edmund Mergl
> mailto:[EMAIL PROTECTED]
> http://www.bawue.de/~mergl
>
