I was cruising with Apache::DBI, definitely better than the way I had it, but now suddenly I'm getting this error:
DBD::ODBC::dr FETCH failed: handle 1 is owned by thread 1e90bdc not current thread b0f18c (handles can't be shared between threads and your driver may need a CLONE method added) at C:/Perl/site/lib/Apache/DBI.pm line 64.
What's going on?
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
