I'm going to change the DBH code. I've witnessed a few problems so far where the DBH has crapped out. I'll try Apache::DBI.
I've been wrapping my head around the reverse proxy cache, I have it set up on my home servers. It seems to be a really good solution for caching, but it's further down the road for me... In the meantime, I'm going to try the CGI::Cache.
Got some work to do :)
Thanks for the tips and explanations,
Paul
Perrin Harkins <[EMAIL PROTECTED]> wrote:
Paul Simon wrote:
> I currently have CGI pages caching on the client side, which
> is helping some, but I'm also going to experiment with CGI::Cache.
There are some mod_perl specific version of this too, like the one from
the mod_perl Developer's Cookbook (Apache::CacheContent), but these are
mod_perl 1.x and probably require work to get them running on mod_perl
2. Traditionally this has mostly been done with a caching reverse
proxy, and that's another angle you could try.
> What kind of trouble is
> there for having use DBI and use HTML::Template in both startup.pl and
> Snoopy.pm (besides being redundant)?
None. That is the right thing to do, because it preloads the modules
(by having them in startup.pl) and documents the dependencies (by
putting in Snoopy.pm).
> Since Snoopy.pm is the meat and
> pototoes, should it also be in startup.pl?
Yes.
> Does declaring Class
> variables, such as the DBI handle, offer any benefits (or pain) of a
> shared connection?
You're getting yourself into major trouble there. You should use
Apache::DBI instead. The way you have it now (with the connection code
in the "main" section of Snoopy.pm), that database connection will be
created when you use the module in startup.pl. Apache will then fork
and multiple children will try to share the same $DBH. Disaster.
Also, your solution will not try to reconnect if it loses its
connection. Apache::DBI will. And you are creating a closure here with
your $DBH which might come back to bite you later if your module gets
automatically reloaded when you change it.
- Perrin