> I'm not sure what you're suggesting. The first few pages of "cache" on
> CPAN have some modules for caching data in memory and on disk and so
> forth, but I don't see how they relate to my problem.
> Which is that of notifying all of my application's perl processes when
> an update has been performed on a table in a database, without having
> them access the database to determine this on their own.

There are two ways of achieving your task:
- active: forcing all the apache processes to update their list of
- passive: having each apache child check on whether the copy of the
list they already have is still up to date

By far the simplest way of achieving the first option is by having the
parent load and cache the list (which means that memory is shared by all
the child processes) and restarting your apache processes when the list

For the passive route, each apache child has to perform some kind of
check to see whether their version is up to date. This requires some
kind of check somewhere, eg:
- checking the last modified time of a file
- loading the list from a cache
- loading the list from the database

Your intention is to reduce the number of database hits. That's fine,
but it needs to be weighed against the cost of inflexibility, or the
cost of checking and rebuilding the cache.

For data that almost never changes, I would go the active route.

For data that changes more regularly, but has a certain time-to-live, I
would go the caching route. For data that changes by the second, get it
directly from the DB.

So searching for 'cache' on CPAN, indeed gives you a number of very
useful modules that ease your path to reducing the number of DB hits
that you have.

My personal favourite is Cache::Memcached, but that's only relevant if
you have more than one web server. If not, the file based caches are
the fastest (or you could try looking at SQLite or Cache::BerkleyDB or
even a memory table in MySQL, but on a different DB server)



> Thanks.
> Colin