This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: mod_perl List <modperl@apache.org>
From: Pierre Phaneuf <pphaneuf@sx.nec.com>
Subject: Re: Odd Caching Bug
Date: Wed, 21 Feb 2001 14:50:28 -0500
Stathy Touloumis wrote:
> 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.
>
> 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.
So, if I understand correctly, the database handle is getting cached
more than you think it should, that's right?
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).
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.
You go to the first page, which sets the ISO format, then you go to the
other using the same connection to the same Apache child process, which
use whatever format is currently set on that connection.
Two solutions:
- 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").
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!
I suggest the second solution, as it will have improved performance over
the first one, as this is the goal of Apache::DBI.
===
To: "Pierre Phaneuf" <pphaneuf@sx.nec.com>
From: "Stathy Touloumis" <stathy.touloumis@edventions.com>
Subject: RE: Odd Caching Bug
Date: Wed, 21 Feb 2001 16:53:26 -0600
> 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.
===