The Cache modules are designed to assist a developer in persisting
data for a specified period of time. Often these modules are used in
web applications to store data locally to save repeated and redundant
expensive calls to remote machines or databases. People have also
been known to use Cache::Cache for its straightforward interface in
sharing data between runs of an application or invocations of a
CGI-style script or simply as an easy to use abstraction of the
filesystem or shared memory.
The Cache::Cache interface is implemented by classes that support the
get, set, remove, size, purge, and clear instance methods and their
corresponding static methods for persisting data across method calls.
Cache::Cache is in wide use and very stable, but has not changed in years
and is no longer actively developed.
CHI is the successor to Cache::Cache. It adheres to the basic
Cache::Cache API but adds new features and drivers (e.g. FastMmap and
Memcached), improves performance, and addresses limitations in the
Cache::Cache implementation. The authors recommend the use of CHI going forward.
Questions about Cache::Cache and CHI may be directed to the perl-cache
mailing list at http://groups.google.com/group/perl-cache-discuss.
First, choose the best type of cache implementation for your needs.
The simplest cache is the MemoryCache, which is suitable for
applications that are serving multiple sequential requests, and wish
to avoid making redundant expensive queries, such as an
Apache/mod_perl application talking to a database. If you wish to
share that data between processes, then perhaps the SharedMemoryCache
is appropriate, although its behavior is tightly bound to the
underlying IPC mechanism, which varies from system to system, and is
unsuitable for large objects or large numbers of objects. When the
SharedMemoryCache is not acceptable, then FileCache offers all of the
same functionality with similar performance metrics, and it is not
limited in terms of the number of objects or their size. If you wish
to maintain a strict limit on the size of a file system based cache,
then the SizeAwareFileCache is the way to go. Similarly, the
SizeAwareMemoryCache and the SizeAwareSharedMemoryCache add size
management functionality to the MemoryCache and SharedMemoryCache
classes respectively.
Using a cache is simple. Here is some sample code for instantiating
and using a file system based cache.
use Cache::FileCache;
my $cache = new Cache::FileCache( );
my $customer = $cache->get( $name );
if ( not defined $customer )
{
$customer = get_customer_from_db( $name );
$cache->set( $name, $customer, "10 minutes" );
}
return $customer;
Construct a new instance of a Cache::Cache. $options_hash_ref is a
reference to a hash containing configuration options; see the section
OPTIONS below.
Returns the underlying Cache::Object object used to store the cached
data associated with $key. This will not trigger a removal
of the cached object even if the object has expired.
Associates $data with $key in the cache. $expires_in
indicates the time in seconds until this data should be erased, or the
constant $EXPIRES_NOW, or the constant $EXPIRES_NEVER. Defaults to
$EXPIRES_NEVER. This variable can also be in the extended format of
"[number] [unit]", e.g., "10 minutes". The valid units are s, second,
seconds, sec, m, minute, minutes, min, h, hour, hours, d, day, days, w,
week, weeks, M, month, months, y, year, and years. Additionally,
$EXPIRES_NOW can be represented as "now" and $EXPIRES_NEVER can be
represented as "never".
Sets the auto purge interval. If this option is set to a particular
time ( in the same format as the expires_in ), then the purge( )
routine will be called during the first set after the interval
expires. The interval will then be reset.
Accesses the auto purge interval. If this option is set to a particular
time ( in the same format as the expires_in ), then the purge( )
routine will be called during the first get after the interval
expires. The interval will then be reset.
Cache::Cache