Thanks for the explanation... So there isn't really any concept of an overall "application", but rather just threads of processing that flow through the childrenservers... So each request runs in its own thread in an arbitrary childserver so there isn't a place to cache stuff in memory...
I think for what we're doing, I can simplify the creation of the objects and then not cache them at all. So far, caching provides a 50% gain. But it has been unreliable as to what I get out and now I see why. :) Ken. -----Original Message----- From: Tod Harter [mailto:[EMAIL PROTECTED] Sent: Friday, November 21, 2003 7:56 PM To: [EMAIL PROTECTED] Subject: Re: lifecycle and variable question 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
