may be the linux ramdisk is another good choice. you can use memory like normal filesystem.
----- Original Message ----- From: "Frank Wiles" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <modperl@perl.apache.org> Sent: Wednesday, September 27, 2006 9:45 PM Subject: Re: mod_perl using IPC::ShareLite > On Wed, 27 Sep 2006 13:13:51 +0100 > "Ben Wilder" <[EMAIL PROTECTED]> wrote: > > > My research so far has led me to believe that IPC::ShareLite could be > > used by the cron job script to set a few (very small) variables into > > a portion of shared memory, that a separate mod_perl application > > could poll. Mod_perl would not need to modify these variables, only > > read them. > > > > Would using a library such as IPC::ShareLite be considered a fudge > > for this type of action, is there some sort of global apache variable > > section that I can modify with one application and read out from > > another? > > > > Any thoughts appreciated! > > Using one of the IPC modules is definitely a reasonable choice > based on what you're trying to do. But I wanted to throw out > some other options as some people find IPC hard to work with. > > 1. BerkeleyDB or sqlite. I realize you said you'd like to avoid a > database, but sometimes this means avoid installing a big > RDMS like PostgreSQL, MySQL, etc. > > 2. memcached and Cache::Memcached could store your data in > a memory cache for you. > > 3. Use can also use a simple config file with something like > Config::General. Your crons can update this data onto disk > and your mod_perl apps can simply read it in as a config file, > maybe using a short 5 minute cache to reduce disk reads. > > 4. You could also use Storable to drop an object full of your > small variables from your cron and have your mod_perl app > read them in on each request ( or a short cache in pnotes or > something ). > > The last two may sound slow due to the disk reads, but it really > shouldn't cause a performance problem in all but the most > demanding environments. > > --------------------------------- > Frank Wiles <[EMAIL PROTECTED]> > http://www.wiles.org > --------------------------------- >
