Hi Eric, As I've demonstrated, I'm still trying to figure out these kinds of questions. After this last incidence, my general approach is to remove all globals. When it comes to mod_perl under Apache 1.3.x, I believe that a global is global to all of your scripts. Apache 2.0 will eventually offer the ability to run specific scripts in specific threads using the perchild MPM <http://httpd.apache.org/docs-2.0/mod/perchild.html> which should help limit the effect of globals. I think this is one reason it's almost impossible to find cheap mod_perl shared hosting whereas mod_cgi and mod_php are installed nearly everywhere. I'd be wary of using $dbh as a global because if you have two scripts which set $dbh to different connection strings, it seems possible that App 1 could be processing a request when App 2 gets called and sets $dbh to a different string. If App 1 then used the new $dbh setting, I'd think you'd have problems. In my scripts, I set the $dbh as an attribute of my CGI::App module and use Apache::DBI to do persistent database connections (or so I presume since it does this transparently). So far, I haven't had any problems with this arrangement even though the two apps that were interacting badly earlier this week use two different databases. Perhaps someone smarter than us can comment on these mysteries. You could also try PerlMonks.org if you don't get a satisfactory answer from the mailing list. Good luck, William On 2 Oct 2002 at 22:50, Eric Frazier wrote: > Hi, > > I am curious. How global is global? I mean for example I will use a db > handle in a module as global with use vars qw($dbh); but the rest is use > strict. The module is a class module with bless and please and thankyou. > > Is this still the kind of thing to big time avoid? So if I run this code > without Apache::DBI I end up with extra db connections, not really very > pretty. But I never thought it would be a big problem. > > Any thoughts? > > Thanks, > > > Eric > > At 12:40 PM 10/2/02 -0400, William McKee wrote: > >In case anyone is thinking of trying to understand my last two posts to > >the list regarding the troubles I've been having with mod_perl and > >CGI::App, I have solved my problem. > > > >The root of all evils in mod_perl scripts are global variables. There was > >a subroutine I used to load the config file which required an external > >file into memory. Both my configuration files used the same global hash > >name which would occassionally get changed when the other script ran. I > >can go into more detail if anyone is interested, but the major problem was > > global variables. > > > >The perl-status pages has been a great resource for helping me track down > >and debug this problem. See > ><http://perl.apache.org/docs/1.0/guide/debug.html#Interactive_mod_perl_Deb > >u gging> for more info on setting this up. > > > >Later, > >William > > > >-- > > Lead Developer > > Knowmad Services Inc. || Internet Applications & Database Integration > > http://www.knowmad.com > > > > > > > >--------------------------------------------------------------------- Web > >Archive: http://www.mail-archive.com/suppressed/ To unsubscribe, > >e-mail: suppressed For additional commands, > >e-mail: suppressed > > > > http://www.kwinternet.com/eric > (250) 655 - 9513 (PST Time Zone) > > "Inquiry is fatal to certainty." -- Will Durant > > > > > -- Lead Developer Knowmad Services Inc. || Internet Applications & Database Integration http://www.knowmad.com --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/suppressed/ To unsubscribe, e-mail: suppressed For additional commands, e-mail: suppressed
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.