Re: PerlFreshRestart and %INC
On Fri, 3 Dec 1999, Tim Bunce wrote: ... But is that _really_ what PerlFreshRestart does? I thought it destroyed the entire perl interpreter before then recreating one from scratch? this is the way PerlFreshRestart works at the moment. the original implementation did destroy the interpreter and re-compile everything from scratch. but perl_destruct() wasn't quite bug free at the time, the current hack was put in it's place, which we found out later, isn't bug free either. we will do it the right way for 2.0, but in the meantime, a complete shutdown and start of the server is the safest way to do a "fresh restart".
Re: PerlFreshRestart and %INC
As far as I know connect_cached didn't show up untill latest versions
of DBI. And unfortunately our production services don't use those
versions.
Though there's still a disclaimer saying that the behaviour is subject
to change. Whatever. Can't I simply get rid of Apache::DBI since DBI
itself offers almost the same thing?
Andrei
On Sun, Dec 05, 1999 at 06:27:50PM -0800, Jeffrey W. Baker wrote:
Tim Bunce wrote:
I've always thought the "must load Apache::DBI before DBI" thing was a
bit weird anyway. Can't you just make it a flag that DBI looks at
that Apache::DBI sets?
The idea was to avoid run-time overhead by setting things up a
compile time.
I guess I could add something like this:
DBI-default_connect_method("Apache::DBI::connect");
which Apache::DBI could call, after a "use DBI;", to get itself
plugged in.
Ew. That is pegging my wankometer. Doesn't connect_cached do the same
thing that most of Apache::DBI does? Why doesn't Apache::DBI just
inherit everything but connect() and disconnect() from DBI?
IMHO Apache::DBI causes more problems than it solves with it's
"transparent" replacement of DBI functions. Can anyone point to an
example where a subclass of DBI would not do everything that Apache::DBI
does, except without the headaches?
-jwb
--
Re: PerlFreshRestart and %INC
On Sun, 5 Dec 1999, Tim Bunce wrote:
I guess I could add something like this:
DBI-default_connect_method("Apache::DBI::connect");
which Apache::DBI could call, after a "use DBI;", to get itself
plugged in.
that would be great, cos ive wanted to be able to supply my
own connect method as well.
Re: PerlFreshRestart and %INC
Tim Bunce wrote:
I've always thought the "must load Apache::DBI before DBI" thing was a
bit weird anyway. Can't you just make it a flag that DBI looks at
that Apache::DBI sets?
The idea was to avoid run-time overhead by setting things up a
compile time.
I guess I could add something like this:
DBI-default_connect_method("Apache::DBI::connect");
which Apache::DBI could call, after a "use DBI;", to get itself
plugged in.
Ew. That is pegging my wankometer. Doesn't connect_cached do the same
thing that most of Apache::DBI does? Why doesn't Apache::DBI just
inherit everything but connect() and disconnect() from DBI?
IMHO Apache::DBI causes more problems than it solves with it's
"transparent" replacement of DBI functions. Can anyone point to an
example where a subclass of DBI would not do everything that Apache::DBI
does, except without the headaches?
-jwb
Re: PerlFreshRestart and %INC
[EMAIL PROTECTED] (Jeffrey W. Baker) wrote: IMHO Apache::DBI causes more problems than it solves with it's "transparent" replacement of DBI functions. Can anyone point to an example where a subclass of DBI would not do everything that Apache::DBI does, except without the headaches? Yes, here's an example: a subclass wouldn't let existing scripts run *unmodified* with persistent connections. That said, I should point out that I tend to wrap my connection() method in a subroutine anyway and call that subroutine from lots of places, so it wouldn't be much hassle to do Apache::DBI-connect(...) instead of DBI-connect(...) . I agree that it would certainly be more intuitive and avoid the load-order gotchas. And support for Apache::DBI could be removed from DBI, which makes sense hierarchically. I don't (yet) see a way to make this interface backward-compatible, so I suppose it deserves a new class name. Apache::PersistentDBI? Apache::CacheDBI? ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: PerlFreshRestart and %INC
Ken Williams wrote: [EMAIL PROTECTED] (Jeffrey W. Baker) wrote: IMHO Apache::DBI causes more problems than it solves with it's "transparent" replacement of DBI functions. Can anyone point to an example where a subclass of DBI would not do everything that Apache::DBI does, except without the headaches? Yes, here's an example: a subclass wouldn't let existing scripts run *unmodified* with persistent connections. Well, yeah. I think that's the point. In any rational world, you wouldn't expect the loading of a class called Apache::DBI to affect the methods of the class called DBI. Apache::DBI is a weird class. Most people never call any methods from it. For them, the incantation 'use Apache::DBI;' is pure voodoo programming. -jwb
Re: PerlFreshRestart and %INC
"Jeffrey W. Baker" [EMAIL PROTECTED] writes:
Ken Williams wrote:
[EMAIL PROTECTED] (Jeffrey W. Baker) wrote:
IMHO Apache::DBI causes more problems than it solves with it's
"transparent" replacement of DBI functions. Can anyone point to an
example where a subclass of DBI would not do everything that Apache::DBI
does, except without the headaches?
Yes, here's an example: a subclass wouldn't let existing scripts run
*unmodified* with persistent connections.
Well, yeah. I think that's the point. In any rational world, you
wouldn't expect the loading of a class called Apache::DBI to affect the
methods of the class called DBI.
Apache::DBI is a weird class. Most people never call any methods from
it. For them, the incantation 'use Apache::DBI;' is pure voodoo
programming.
It's a good example of the "action at a distance" idea. It's useful,
though, so we can forgive some amount of trouble :) It would be nice
to see a DBD::Apache or DBD::Shared DBD module, so that you could call
something like:
my $db = DBI-connect("shared;dbd=mysql;db=mydb;host=foo.com", "myuser",
"mypw");
Then the DBD module could handle the caching of handles at that
level. Or as suggested above you could subclass DBI.
I think we should provide both a clean, well-designed interface for
general use, and an interface that works with existing scripts
un-modified. Come to think of it, most cases that would want to run
unmodified probably are Apache::Registry scripts. Perhaps the db
handle caching belongs somewhere with Registry, much as it handles
caching of parsed scripts? There would be a certain aesthetic value
of Registry caching dbh's as well as scripts and letting a separate,
on-demand module handle general caching for typical handlers to use.
Even nicer would be Registry using that same higher level mechanism
with only slight amounts of magic :)
Like $[, Apache::DBI serves a purpose for backwards compatibility (in
this case old CGI scripts instead of odd perl4 scripts), but it
probably should be disdained in general use, at least once a suitable
replacement is available. Now, who wants to write it? :)
Chip
--
Chip Turner [EMAIL PROTECTED]
Programmer, ZFx, Inc. www.zfx.com
PGP key available at wwwkeys.us.pgp.net
Re: PerlFreshRestart and %INC
Foolishness alert/Newbie approaches. Hate that this thread died. Was following it to get some insights into the nether regions. I read some doc about DBI or Apache/DBI pinging or doing some kind of trace on the other when a db connection was attempted. I thought it made the point that Apache/DBI was not loaded until a connection was attempted by DBI.pm. Would appreciate a heads up on what doc that was. Can't find it again. *sigh* Thanks, Michael Dearman
RE: PerlFreshRestart and %INC
I'm not sure about why it behaves this way, but the mod_perl guide forewarns
that "Evil things might happen when using PerlFreshRestart"
check out
http://perl.apache.org/guide/troubleshooting.html#Evil_things_might_happen_w
hen_us
which lists the relevant code...
maybe it has to do with the order in which stuff is held in %INC - that is,
Apache::DBI needs to be loaded before DBI, but PerlFreshRestart may require
them in the improper order because of the hash order?
--Geoff
-Original Message-
From: Tim Bunce [SMTP:[EMAIL PROTECTED]]
Sent: Thursday, December 02, 1999 7:07 PM
To: Michael Smith
Cc: mod_perl mailing list; Tim Bunce; Doug MacEachern
Subject: Re: PerlFreshRestart and %INC
On Thu, Dec 02, 1999 at 06:59:26PM +, Michael Smith wrote:
I'm experiencing difficulties when using PerlFreshRestart modules that
depend on %INC. In my particular case I'm trying to use persistent
connections in DBI through Apache-DBI, and Apache/DBI is not in %INC
when PerlFreshRestart causes DBI to be loaded a second time.
In more detail, I've cut down my config file to little more than
PerlModule Apache::DBI
And I've altered DBI.pm to Dump out %INC to STDERR just before it checks
it to see if it contains Apache/DBI. With PerlFreshRestart not set I
get this dumped out in my session.
$VAR21 = 'Apache/DBI.pm';
With PerlFreshRestart on, I get two dumps, one in my session window, and
one in the error log; firstly:
$VAR21 = 'Apache/DBI.pm';
(just as above) and then in the error log.
[...similar list but without Apache/DBI.pm...]
Why does PerlFreshRestart behave like this? I don't understand why the
module is loaded twice, and more particularly why %INC is different the
second time. Oh, I suppose I should mention that this is with
perl5.00404, apache/1.3.6 and mod_perl/1.19
And just to fill-in from the DBI perspective... near the top of DBI.pm
it says:
# check if user wants a persistent database connection ( Apache +
mod_perl )
if ($INC{'Apache/DBI.pm'} substr($ENV{GATEWAY_INTERFACE}||'',0,8) eq
'CGI-Perl') {
$connect_via = "Apache::DBI::connect";
DBI-trace_msg("DBI connect via $INC{'Apache/DBI.pm'}\n");
}
So the problem seems to be that when the DBI gets re-loaded by
PerlFreshRestart, %INC doesn't contain 'Apache/DBI.pm'. Presumably
because Apache::DBI hasn't been loaded (yet?).
So, as Mike says, any ideas why PerlFreshRestart behaves like this?
Tim.
RE: PerlFreshRestart and %INC
that's what I meant :)
Since %INC is a hash, and it's order unpredictable, it's possible that DBI
be re-required before Apache::DBI. But maybe something else is going on
too...
here's the code from the guide:
while (my($k,$v) = each %INC) {
delete $INC{$k};
require $k;
}
--Geoff
-Original Message-
From: G.W. Haywood [SMTP:[EMAIL PROTECTED]]
Sent: Friday, December 03, 1999 10:04 AM
To: mod_perl Mailing List
Subject: RE: PerlFreshRestart and %INC
Hi there,
On Fri, 3 Dec 1999, Young, Geoffrey S. wrote:
maybe it has to do with the order in which stuff is held in %INC - that
is,
Apache::DBI needs to be loaded before DBI, but PerlFreshRestart may
require
them in the improper order because of the hash order?
Is there a `hash order'?
Hashes can do strange things with the order of their contents.
Does the code do a foreach (sort keys %INC) or just foreach (%INC) ?
73
Ged.
Re: PerlFreshRestart and %INC
On Fri, Dec 03, 1999 at 12:00:38PM -0500, Young, Geoffrey S. wrote:
that's what I meant :)
Since %INC is a hash, and it's order unpredictable, it's possible that DBI
be re-required before Apache::DBI. But maybe something else is going on
too...
here's the code from the guide:
while (my($k,$v) = each %INC) {
delete $INC{$k};
require $k;
}
Well that would certainly cause the problem.
But is that _really_ what PerlFreshRestart does? I thought it destroyed
the entire perl interpreter before then recreating one from scratch?
I presumed (I've not looked) that it would reload the new interpreter
in the same way that the original one was and thus would reload modules
in the same order.
Tim.
Re: PerlFreshRestart and %INC
"Tim" == Tim Bunce [EMAIL PROTECTED] writes: Tim I presumed (I've not looked) that it would reload the new interpreter Tim in the same way that the original one was and thus would reload modules Tim in the same order. You can *presume* that, but I don't recall anywhere in the Perl interpreter where *order* of require's is recorded. I've always thought the "must load Apache::DBI before DBI" thing was a bit weird anyway. Can't you just make it a flag that DBI looks at that Apache::DBI sets? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: PerlFreshRestart and %INC
[EMAIL PROTECTED] (Tim Bunce) wrote:
On Fri, Dec 03, 1999 at 12:00:38PM -0500, Young, Geoffrey S. wrote:
that's what I meant :)
Since %INC is a hash, and it's order unpredictable, it's possible that DBI
be re-required before Apache::DBI. But maybe something else is going on
too...
here's the code from the guide:
while (my($k,$v) = each %INC) {
delete $INC{$k};
require $k;
}
Well that would certainly cause the problem.
I'm not so sure of that. Isn't the following timeline accurate?
1) Apache::DBI loads for the first time
2) DBI loads for the first time, notices that Apache::DBI is loaded, and
makes appropriate adjustments.
3) ...time passes...
4) PerlFreshRestart happens, and either DBI or Apache::DBI gets
deleted/reloaded first. Either way, there will be an entry for
'Apache/DBI.pm' in %INC when DBI is reloaded.
Right?
It appears that the following XS code from perl_utils.c is actually
used, which (I think) is equivalent.
void perl_reload_inc(void)
{
HV *hash = GvHV(incgv);
HE *entry;
I32 old_warn = dowarn;
dowarn = FALSE;
hv_iterinit(hash);
while ((entry = hv_iternext(hash))) {
char *key = HeKEY(entry);
SvREFCNT_dec(HeVAL(entry));
HeVAL(entry) = sv_undef;
MP_TRACE_g(fprintf(stderr, "reloading %s\n", key);)
perl_require_pv(key);
}
dowarn = old_warn;
}
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
Re: PerlFreshRestart and %INC
On Thu, Dec 02, 1999 at 06:59:26PM +, Michael Smith wrote:
I'm experiencing difficulties when using PerlFreshRestart modules that
depend on %INC. In my particular case I'm trying to use persistent
connections in DBI through Apache-DBI, and Apache/DBI is not in %INC
when PerlFreshRestart causes DBI to be loaded a second time.
In more detail, I've cut down my config file to little more than
PerlModule Apache::DBI
And I've altered DBI.pm to Dump out %INC to STDERR just before it checks
it to see if it contains Apache/DBI. With PerlFreshRestart not set I
get this dumped out in my session.
$VAR21 = 'Apache/DBI.pm';
With PerlFreshRestart on, I get two dumps, one in my session window, and
one in the error log; firstly:
$VAR21 = 'Apache/DBI.pm';
(just as above) and then in the error log.
[...similar list but without Apache/DBI.pm...]
Why does PerlFreshRestart behave like this? I don't understand why the
module is loaded twice, and more particularly why %INC is different the
second time. Oh, I suppose I should mention that this is with
perl5.00404, apache/1.3.6 and mod_perl/1.19
And just to fill-in from the DBI perspective... near the top of DBI.pm
it says:
# check if user wants a persistent database connection ( Apache + mod_perl )
if ($INC{'Apache/DBI.pm'} substr($ENV{GATEWAY_INTERFACE}||'',0,8) eq 'CGI-Perl') {
$connect_via = "Apache::DBI::connect";
DBI-trace_msg("DBI connect via $INC{'Apache/DBI.pm'}\n");
}
So the problem seems to be that when the DBI gets re-loaded by
PerlFreshRestart, %INC doesn't contain 'Apache/DBI.pm'. Presumably
because Apache::DBI hasn't been loaded (yet?).
So, as Mike says, any ideas why PerlFreshRestart behaves like this?
Tim.
