Perrin Harkins wrote:
> You could still be foiling it
> by stashing database handles in globals or closures though.
Thanks a lot, Perrin, in fact this helped a lot. You convinced me that
it's my error :)
The idea that one db handle is being inherited by the forked childs
helped. I finally found one place where I forgot to add connect_method
=> "connect" to override Apache::DBI back to DBI. Everything is fine,
thanks!
> > # here's a workaround to override DBI methods with Apache::DBI ones
> > {
> > package DBI;
> > $connect_via = "Apache::DBI::connect";
> > }
>
> Ack! Don't do that! Just load Apache::DBI at the top of your
> httpd.conf like it says to in the docs.
Nope. Look inside DBI.pm - this is a fair hack.
> > $Counter::db and $Counter::db->reconnect;
> >
> > unless ($Counter::db) {
> > $Counter::db ||= MySQL::Tools->dbopen( @Counter::INI::DBopendata )
> > or croak MySQL::Tools->errstr;
> > }
>
> That looks like a problem to me. Don't put database handles in
> globals. You will regret it. If any code like this gets run outside of
> a sub in a module that is use()ed during startup, you would get sharing
> of handles between processes.
No, it works perfect, just you should be sure you initialise handles
after childs are forked - i.e. in sub handler - not in BEGIN or any
early stage.
These globals let me have just one DB handle per child, instead of 7
handles! :) Having 10-15 childs active this saves a lot of mysql
threads.
Actually even if you have few PerlHandler modules with their sub
handler's - each time the child executes just one of them and so it's
safe to reuse the same connection.
Thanks! It's solved!
--
==================================
Mike Blazer
[EMAIL PROTECTED]
==================================
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
