I don't know the details, but there is something about the way
PerlModule works in mod_perl 1 that causes it to load the module again
when apache restarts at startup (it runs yours conf file twice when
you start, as documented). Using an explicit use() puts an entry in
%INC and fixes the
Quoting Perrin Harkins [EMAIL PROTECTED]:
How are you loading this? With a PerlModule call? Can you try
loading it from a Perl section like this?
Perl
use MyModule;
/Perl
Wow, it seems that this fixes the problem! At least with my minimal application.
Here's the debug output which looks
Quoting Tobias Kremer [EMAIL PROTECTED]:
Quoting Perrin Harkins [EMAIL PROTECTED]:
How are you loading this? With a PerlModule call? Can you try
loading it from a Perl section like this?
Perl
use MyModule;
/Perl
Wow, it seems that this fixes the problem!
Do you have any idea what
On Wed, Jul 2, 2008 at 5:12 AM, Tobias Kremer [EMAIL PROTECTED] wrote:
No more errors there either! :)
Great!
I don't know anything about the internals but to me the mod_perl source looks
like PerlModule is using require instead of use to load modules. I guess
that is making the difference?
Quoting Perrin Harkins [EMAIL PROTECTED]:
On a closer look, you're not. You are keeping around your $foo
closure variable in handler(), as well as putting it in a global.
It's not obvious why that causes this problem. If you want to
determine whether Apache::DBI is malfunctioning for you in
On Tue, Jul 1, 2008 at 3:42 AM, Tobias Kremer [EMAIL PROTECTED] wrote:
Removing Apache::DBI makes the errors go away.
Ok. First, check that you're on the latest version. Then, turn on
the debug flag and see if it thinks it is reusing the startup
connection or not.
- Perrin
Quoting Perrin Harkins [EMAIL PROTECTED]:
Ok. First, check that you're on the latest version. Then, turn on
the debug flag and see if it thinks it is reusing the startup
connection or not.
Yes, I'm using the latest 1.07 release. I already had the debug flag on and it's
correctly telling me
On Tue, Jul 1, 2008 at 9:56 AM, Tobias Kremer [EMAIL PROTECTED] wrote:
Yes, I'm using the latest 1.07 release. I already had the debug flag on and
it's
correctly telling me that it's skipping connection during server startup.
Yes, but what does it tell you on the first connection AFTER
Quoting Perrin Harkins [EMAIL PROTECTED]:
Yes, but what does it tell you on the first connection AFTER startup?
It should say whether it's making a new connection or not.
Here's the complete debug output which suggests that the connection during
startup is reused for the first request.
On
On Tue, Jul 1, 2008 at 10:08 AM, Tobias Kremer [EMAIL PROTECTED] wrote:
On server start:
20097 Apache::DBI skipping connection during server startup, read the docu !!
20097 Apache::DBI push PerlCleanupHandler
20097 Apache::DBI need ping: yes
20097 Apache::DBI new connect
Quoting Perrin Harkins [EMAIL PROTECTED]:
On Mon, Jun 30, 2008 at 4:54 AM, Tobias Kremer [EMAIL PROTECTED] wrote:
We never fork and I thought that Apache::DBI takes care of checking if a
connection went stale by utilizing DBI's/DBD::mysql's ping() method?
It does, but it can't stop you from
On Mon, Jun 30, 2008 at 9:28 AM, Tobias Kremer [EMAIL PROTECTED] wrote:
Ok, I narrowed it down to the database connection initiated during server
startup. As soon as I remove it the errors vanish completely.
Good, that's major progress.
Here are some snippets to illustrate what I'm doing:
I
Quoting Perrin Harkins [EMAIL PROTECTED]:
I don't see anything in this code, but you're not really showing us
much here. I think you'll need to try commenting out parts of it
until you find which part breaks it. I'd start with that
selectall_arrayref that you store.
I can reproduce the
Tobias Kremer wrote:
use vars qw( $dbh $thefoo );
Why are you storing the DB handle in a global variable?
If you do that then Apache::DBI can't help you if the connection goes away.
--
Michael Peters
Plus Three, LP
Quoting Michael Peters [EMAIL PROTECTED]:
Tobias Kremer wrote:
use vars qw( $dbh $thefoo );
Why are you storing the DB handle in a global variable?
If you do that then Apache::DBI can't help you if the connection goes away.
To make this variable available to all Mason components.
Tobias Kremer wrote:
Quoting Michael Peters [EMAIL PROTECTED]:
Why are you storing the DB handle in a global variable?
If you do that then Apache::DBI can't help you if the connection goes away.
To make this variable available to all Mason components.
Then use a method to do this, not a
On 30.06.2008, at 17:10, Perrin Harkins wrote:
It's not Apache::DBI that's caching it -- you're caching it. Don't
put a database handle in a global before you fork. It will stay, and
there's nothing Apache::DBI can do about it.
Could you please show me the exact line in my example in which I
On Mon, Jun 30, 2008 at 1:40 PM, Tobias Kremer [EMAIL PROTECTED] wrote:
Could you please show me the exact line in my example in which I put the
database handle in a
global during startup?
On a closer look, you're not. You are keeping around your $foo
closure variable in handler(), as well as
18 matches
Mail list logo
