perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Gormley < >
Subject Re: mod_perl implementation possibility
Date Fri, 16 Mar 2007 17:20:28 GMT
> thanks! I actually have an example of this. A module
> for event logging purpose. the global variable is a
> hash consists a set of default log flags corresponding
> to log messages. 
> i can register a new flag/msg to the global variable
> in my app and go on with the logging. a simplified
> version :
> package EventLogging;
> my %EVENT_TYPES = ( log_in_ok => 'Login OK', .. );
> sub add_event { 
>     my ($self, $your_event) = @_;
>     while ( my ($k, $v) = each %$your_event ) {
>         $EVENT_TYPES{ $k } = $v;
>     }
> }
> use EventLogging;
> my $elog = EventLogging->new()
> $elog->add_event({...});
> now under mod_perl with few apps sharing the same
> module, what's the best way to solve this problem ?

Well, depends how you're using it.

1) If you create a new EventLogging instance at the beginning of your
application, which you continue to use throughout the application, then
store the added events in the object itself.

For instance: (I'm assuming that EventLogging->new returns a blessed
hashref rather than some other form of object)

  sub add_event {
      my $self = shift;
      my ($name,$description) = @_;
      $self->{_events}->{$name} = $description;
      return $self->{_events} # or whatever

  sub get_event {
      my $self = shift;
      my $name = shift;
      die "Event '$name' doesn't exist"
          unless exists $self->{_events}->{$name};
      return $self->{_events}->{$name}

2) Maybe you don't want to keep an instance of EventLogging lying around
and you want to just use class methods to set the events at startup, and
then get a new event object whenever you want it.

Then you could subclass EventLogging for each application, eg:

   package AppOne::EventLogging;
     use base 'EventLogging';

   package EventLogging;

   my %Events;

   sub get_event {
      my $self = shift;
      my $class = ref $self || $self;
      my $name = shift;
      die "Event '$name' doesn't exist"
          unless exists $Events{$class}->{$name};
      return $Events{$class}->{$name}


      my $event = EventLogging->new();
      my $description = $event->($name);

> 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.

> > hth
> > 
> > Clint
> > 
> > 
> thanks,
> James.
> ____________________________________________________________________________________
> Finding fabulous fares is fun.  
> Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.

View raw message