[tpm] Using mod_perl
adam.prime at utoronto.ca
adam.prime at utoronto.ca
Fri Apr 18 10:29:59 PDT 2008
Quoting Indy Singh <indy at indigostar.com>:
> 1) Multiple apache/mod_perl instances
> After making a change to the script and pressing refresh in the browser,
> sometime the script works sometimes it gives an error. I know from past
> experience that the browser requests will be processed by one of several
> apache instances. How do you force all mod_perl instances to reset
> everything and start with a fresh instance? Is it enough just to update
> the script source? If I update the source code, will all the apache
> instances reload the script?
The 100% reliable way to do this is to restart apache. this works
under mp1 and mp2. With stuff running under Registry or PerlRun,
Apache::Reload, and Apache2::Reload should work, though I personally
have had some strange experiences with Apache2::Reload and generally
don't use it anymore.
> 2) Browser caching
> When I fetch a result page by clicking on a link, the browser could
> decide to redisplay the same (out-of-date) output as the last time the
> page was fetched. How do you get the browser to fetch a new result each
> time? Does it happen automaticy if the script output does not contain a
> date header?
$r->no_cache(1) will set response headers such that browsers will not
cache the page. It's the same in mp1 and mp2.
> 3) Caching of database handles.
> I am assuming that in my script I can cache a mysql database handle and
> thus avoid a new database connection, however what happens if the
> database connection has been abandoned by the database server? I don't
> know if such a thing is possible, but I trying to program defensively.
> I am thinking that at some point for whatever reason the database server
> droped the connection, but the mod_perl script does not know about it.
> The script tries to uses the old database handle and will fail. Would a
> good way to handle that be to display an error message to the browser
> and close the database connection (just in case it is still open) and
> then set the database handle to undef?
Apache::DBI does this, both under mp1 and mp2. Apache::DBI runs
$dbh->ping on handles it has cached, and if the ping fails then it
creates a new connection (as far as i understand it). You can't share
connections between processes, so you'll still end up with multiple
open connections at any given time, but you won't have to connect and
disconnect with every request which saves a lot of overhead.
Even if you are using Apache::DBI it's still possible that the
database will just 'go away' for whatever reason, so you need to build
checks that your connect calls actually worked, just as you normally
More information about the toronto-pm