perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Wiles <fr...@wiles.org>
Subject Re: mod_perl implementation possibility
Date Fri, 16 Mar 2007 18:30:08 GMT
On Fri, 16 Mar 2007 18:20:28 +0100
Clinton Gormley <clint@traveljury.com> wrote:

> > mod_perl has an excellent document. but is there a
> > checklist kind of thing for running mod_perl in
> > environment like this? where can i read more about
> > this?
> 
> Not that I know of, but if you just think of mod_perl being one big
> application, with multiple entry points. So just avoid doing anything
> that would affect the running of other parts of The Program. 
> 
> It's the same way you program now.  You're aware of the shared parts
> of your code.  You know that if you change the current working
> directory in sub 1, that it's still going to be changed when sub 2 is
> called.  It's the same.
> 
> One other thing to remember is that you need to be careful at startup
> with anything that opens a process, or with DBI handles.  If, during
> startup, you open a connection to the database (or to memcached for
> instance), you will have a problem if you try to continue using that
> connection. Apache starts the parent process, then forks and starts
> all the children that do the work.  If the children are using an old
> connection/db handler/etc, they will be trying to share it, and that
> don't work!  Either delay your connections until after startup, or
> make sure that you're not reusing the old connections.
> 
> Apache::DBI will help you here.
> 
> However, you SHOULD load your modules and setup your configuration
> before forking, because that way each child doesn't have to do it, and
> all that data is shared, so you save a lot on memory.

   +1, I think that's a great description of the major caveats to coding
   in mod_perl.  

 ---------------------------------
   Frank Wiles <frank@wiles.org>
   http://www.wiles.org
 ---------------------------------


Mime
View raw message