Yes, however the trouble comes when you modify an object and then tell the cache to reload it... You're only telling the cache of the current process, not all processes. So then you get some processes that know about the change and some that do not. But if it was just simply caching simple things that only needed loading once and never were modified, it should work.
Ken. -----Original Message----- From: Steve Willer [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 12:58 PM To: Ken Burcham Cc: [EMAIL PROTECTED] Subject: RE: lifecycle and variable question On Mon, 24 Nov 2003, Ken Burcham wrote: > 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. :) Doesn't caching by definition mean that you can't assume the cached object exists? If you have code that builds the objects when cached versions expire or aren't built yet, then you should still get most of the benefits of a single-process, state architecture with persistent objects. > -----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] > > > > --------------------------------------------------------------------- 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]
