RE: Odd Caching Bug
So, if I understand correctly, the database handle is getting cached more than you think it should, that's right? I was unsure where the caching was occurring. I think MaxRequestsPerChild doesn't actually cut off a connection that is kept alive (with KeepAlive). Ctrl-N in a browser could validly reuse the same connection if it is still around (if you wait too long, a keep-alive connection will be closed). This would make sense. It would seem that 'KeepAlive' keeps the 'request' open until it times out. So even though you've set up MaxRequestsPerChild to 1, each Apache child process could be serving multiple requests over a single TCP/IP connection. The answer to "where the caching is occuring" would be in Apache::DBI, which opens a single DB connection per Apache child process. - stop using Apache::DBI. - have your scripts explicitly set the date format they want every time (do not rely on "whatever format is already there"). Actually these are both not options : ) We really are not allowing developers to modify global database variables. This is the first no-no. Because it is not a strict policy somebody obviously abused it : ) With both solutions, you'll be able to leave the keep-alive enabled and use a saner MaxRequestsPerChild (like the default setting). Having "MaxRequestsPerChild 1" is harsh on resources! Understandably the configuration is not optimized but it is only in a development environment to allow for simultaneous development of modules, components and visual elements. Our production environment varies significantly in it's configuration directives. Thanks for the information though. It clarified what I was originally thinking. Thanks,
Odd Caching Bug
Hello,
One of the developers I currently am working with has found an odd bug that
can be replicated on several workstations. First my configuration :
Apache 1.3.17
mod_perl 1.25
Mason (Ancient)
Apache::DBI .88
Postgres 7
MaxRequestsPerChild 1
KeepAlive on
We have two components that contain the following code. One of which
changes a session variable (datestyle to 'ISO')on the postgres database.
Theoretically the two components should return different results based on
the specific datestyle settings ('ISO' and default). This only occurs when
two browsers are opened independently that do not share the same session.
When using ctrl-n on a windows client to open a new window it appears that
they share session information and possibly the same tcp/ip connection(?).
When reloading the components in the two windows eventually they both return
the 'ISO' format date. After pausing for several minutes and reloading the
component that DOES NOT explicitly set the 'ISO' format variable, it
correctly returns the default date format.
--COMPONENT 1--
%perl_init
my $dbh = Edventions::Utilities-new-getDbHandle; ## Uses Apache::DBI to
connect
my $sql = q( select now() as today );
my $sth = $dbh-prepare( $sql );
$sth-execute;
my $now = $sth-fetch-[0];
/%perl_init
h1% $now %
--COMPONENT 2--
%perl_init
my $dbh = Utilities-new-getDatabaseHandle; ## Uses Apache::DBI to connect
my $sql = q( set datestyle to 'ISO'; select now() as today );
my $sth = $dbh-prepare( $sql );
$sth-execute;
my $now = $sth-fetch-[0];
/%perl_init
h1% $now %
Now when the apache directive KeepAlive is set to 'off' this problem does
not occur. I am trying to figure out where the caching is occurring or if
the database handle is not getting properly destroyed for each request.
Any suggestions as to why this is occurring would be greatly appreciated.
Thanks,
Odd Caching Bug
Hello,
One of the developers I currently am working with has found an odd bug that
can be replicated on several workstations. First my configuration :
Apache 1.3.17
mod_perl 1.25
Mason (Ancient)
Apache::DBI .88
Postgres 7
MaxRequestsPerChild 1
KeepAlive on
We have two components that contain the following code. One of which
changes a session variable (datestyle to 'ISO')on the postgres database.
Theoretically the two components should return different results based on
the specific datestyle settings ('ISO' and default). This only occurs when
two browsers are opened independently that do not share the same session.
When using ctrl-n on a windows client to open a new window it appears that
they share session information and possibly the same tcp/ip connection(?).
When reloading the components in the two windows eventually they both return
the 'ISO' format date. After pausing for several minutes and reloading the
component that DOES NOT explicitly set the 'ISO' format variable, it
correctly returns the default date format.
--COMPONENT 1--
%perl_init
my $dbh = Edventions::Utilities-new-getDbHandle; ## Uses Apache::DBI to
connect
my $sql = q( select now() as today );
my $sth = $dbh-prepare( $sql );
$sth-execute;
my $now = $sth-fetch-[0];
/%perl_init
h1% $now %
--COMPONENT 2--
%perl_init
my $dbh = Utilities-new-getDatabaseHandle; ## Uses Apache::DBI to connect
my $sql = q( set datestyle to 'ISO'; select now() as today );
my $sth = $dbh-prepare( $sql );
$sth-execute;
my $now = $sth-fetch-[0];
/%perl_init
h1% $now %
Now when the apache directive KeepAlive is set to 'off' this problem does
not occur. I am trying to figure out where the caching is occurring or if
the database handle is not getting properly destroyed for each request.
Any suggestions as to why this is occurring would be greatly appreciated.
Thanks,
