Hi,
You're making this much harder than it needs to be. For one thing, this
is the wrong place to use inheritance, and for another, globals are okay
if used intelligently.
A database handle is a bad example. You actually should use Apache::DBI
for that, since it will make sure the handle hasn't timed out and deal
with rolling back any pending transactions if your code dies. So, your
dbh() method should probably call DBI->connect() every time, or possibly
stash the $dbh in $r->pnotes(), which gets cleared at the end of a
request.
But let's suppose you had something else you wanted to access this way,
like maybe a special parser object that you wrote which takes a while to
create. Here's how to do it without inheritance:
package Matt::Resources;
our $Parser;
get_parser {
if (!$Parser) {
$Parser = Matt::Parser->new();
}
return $Parser;
}
1;
... and then ...
use Matt::Resources;
my $parser = Matt::Resources->get_parser();
> The dbh method in the master is set so that it checks if there's an
> existing handle and uses it where possible. I have put in some debugging
> that reports the sequence of requests. For CGI it looks as you'd expect
> if things were ok. For example:
>
> CGI: loaded
> CGI: found
> CGI: found
>
> When I run under mod_perl I get the same results on the first hit but
> for subsequent hits I get the following:
>
> CGI: found
> CGI: loaded
> CGI: found
> CGI: found
I think that's just because you're hitting multiple child processes. Or
is this definitely all from a single request? Try running with httpd -X
(to make it single-process), or just print $$ (the process ID) along
with the message.
> I also thought perhaps I might have misunderstood and shouldn't have the
> "our" in the client object so I tried it without it but got the same
> result which is in itself confusing.
You're right, you shouldn't have an "our" in the client object. The
"our" makes a variable global. You should use a lexical "my" variable
in the client code.
- Perrin
