Hi,
Thanks for the detailed information that's great. A couple of things
though.
> 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.
I am using Apache::DBI and would be at a loss without it (we use Oracle
so the connection overhead is serious). With this in mind is it such a
bad thing to hang on to the one handle for an execution? My
understanding was Apache::DBI would reconnect it in the unlikely event
of a timeout during the operation.
I have found this is also useful in that the code still runs reasonably
efficiently under CGI which I find much easier to do early development
work with given I know I'm always executing the changed code.
Secondly, I use the inherited object to achieve some other general but
more complicated logic like logging and error handling which might be
why it looked like overkill. I suppose you could still argue that but it
makes things nice and neat. It dramatically improves the readability
too.
> 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();
I assume that if I did continue to use inheritance then the following
(after the inheritance was set up) would be the equivalent and that the
fact it was inherited at the time will make no difference?
my $parser = $self->get_parser();
> 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.
Hmmm, you're right they're from different processes but I don't
understand how. I put the process ID in and got the following:
(25829): loaded
(25829): returned
(25829): returned
(25829): returned
(25829): returned
(25842): loaded
(25842): returned
(25842): returned
(25842): returned
There's newlines outputted at the very end of the execution so it's
confusing as to how the top line which is part of the process for the
previous hit can be a) output after the newlines and b) output only
after the next request is made. I tried turning off buffering to no
avail. Although the server is running in multi-process mode I am the
only user.
> > 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.
I thought so, was struggling as to how it could associate the two.
Thanks again,
Matt.
