Well, this question is best answered by understanding the processing model
used by Apache, preforking. When Apache starts up the master process first
processes the httpd.conf file. At this point there is one copy of Apache and
mod_perl in existence. The only way you can run anything at this point is to
put code in a file included with PerlRequire or PerlModule directives (or
inside a <perl> section).
Once Apache has finished initializing it then forks MinSpareServers children.
Each of these children now has an exact clone of the perl environment as it
was at that moment. At this point each child calls any PerlChildInitHandler
which has been declared.
As requests are received the main apache process hands them off to any child
which happens to be idle (and may create and destroy children as needed,
always forking them from itself).
Thus the environment is that you will have several copies of mod_perl, each
randomly handling a subset of all page requests, and each with a completely
separate set of variables! Thus if you create a global hash at startup time
(say in a PerlRequire'd module) every child will see that hash, in exactly
that state, the FIRST time it handles a request. Any changes a child makes
will ONLY be visible to that child.
So if you do as you say and create a hash to use as an object cache, then each
child will fill its copy with different objects. This is OK if you only READ
from the cache, but every time an object is WRITTEN you will need to flush it
back to the backing store (database), and furthermore you would need to
invalidate that object in EVERY child's version of the cache. This IS
possible using IPC (shared memory, etc) but the truth is it simply isn't
worth it. In-memory object caches in mod_perl are for the birds.
Now, maybe with mod_perl 2 on Apache2 with a multi-threaded MPM and assuming
we get 'solar variables' it would be possible to use in-memory object caches
in a practical way, but then your code will be horribly non-portable since it
would only work in one MPM (IE, it might work on Win2k server, but not on
Linux in general).
On Thursday 20 November 2003 1:58 pm, Ken Burcham wrote:
> Hi there,
>
> I'm a little unclear on the lifecycle of things with axkit, mod_perl
> and the like. For example, if in an xsp I look at a local file using
> XML::Simple to grab some configuration information (like location of a
> log4perl config file, server name, etc) can I do that lookup just once
> and stuff it somewhere like an application server variable? Or is that
> type of information better suited somewhere else (httpd.conf?). Or does
> my xsp have to look that info up every time it is called?
>
> Also, (and maybe this is just a simple perl question) if I have a perl
> package like the following:
>
> package some::package;
>
> my %cacheofobjects = {};
>
> sub add2cache
> {
> my $this = shift;
> my $obj = shift;
> my $name = $obj->name;
> $cacheofobjects{$name} = $obj;
> }
>
> sub getfromcache
> {
> my $this=shift;
> my $name = shift;
> return ($cacheofobjects{$name});
> }
>
> that my xsp uses to cache objects between hits, where does this cache
> live? Or does it? I'm afraid I don't understand the lifecycle of perl
> objects esp in the context of axkit. Thanks in advance for your help!
>
> Ken.
--
Tod Harter
Giant Electronic Brain
http://www.giantelectronicbrain.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
