lib/Cache/BDB.pod

=head1 NAME

Cache::BDB - An object caching wrapper around BerkeleyDB

=head1 SYNOPSIS

 use Cache::BDB;
 my %options = (
    cache_root => "/tmp/caches",
    namespace => "Some::Namespace",
    default_expires_in => 300, # seconds
 );

 my $cache = Cache::BDB->new(%options);

 #
 # [myshellprompt:~]$ find /tmp/caches
 # /tmp/caches/Some::Namespace/
 # /tmp/caches/Some::Namespace/Some::Namespace.db
 # /tmp/caches/Some::Namespace/__db.001
 # /tmp/caches/Some::Namespace/__db.002
 # /tmp/caches/Some::Namespace/__db.003
 #

 $cache->namespace(); # returns "Some::Namespace", read only
 $cache->default_expires_in(); # returns 300
 $cache->default_expires_in(600); # change it to 600

 $cache->set(1, \%some_hash);
 $cache->set('foo', 'bar');
 $cache->set(20, $obj, 10);

 $cache->add(21, 'whatever'); # works, nothing with the key '21' set yet.
 $cache->add(21, 'coffeepot'); # fails, can only add() something that hasn't
                               # yet been set

 $cache->replace(21, 'shoelace'); # replaces the data 'whatever' with
                                  # 'shoelace'
 $cache->replace(7, 'tattoo'); # fails key/value pair was never set() or
                               # add()ed previously

 my $h = $cache->get(1); # $h and \%some_hash contain the same data
 my $bar = $cache->get('foo'); # $bar eq 'bar';
 my $obj = $cache->get(20); # returns the blessed object

 $cache->count() == 3;
 # assuming 10 seconds has passed ...
 $cache->is_expired(20); # returns true ..
 $cache->purge();
 $cache->get(20); # returns undef
 $cache->count() == 2;

 my $hr = $cache->get_bulk();

 # $hr = {1  => {contents_of => '%some_hash'},
 #        21 => 'shoelace' };

 $cache->close(); # close the cache object

=head1 DESCRIPTION

This module implements a caching layer around BerkeleyDB
for object persistence. It implements the basic methods necessary to
add, retrieve, and remove objects. The main advantage over other
caching modules is performance. I've attempted to stick with a
B<Cache::Cache>-like interface as much as possible, though it may differ
here and there.

=head1 DEPENDENCIES

I've been developing using a very recent version of Berkeley DB
(v4.4.20) and BerkeleyDB (v0.27). I'm pretty sure that most of the
functionality the module relies on is available in Berkeley DB version
3 and higher, but so far I have not tested with older versions. I'm
open to making version specific concessions if necessary. If at all
possible, I would advise you to upgrade both Berkeley DB and
BerkeleyDB to their latest respective versions.

Cache::BDB currently serializes everything it stores with Storable.

=head1 PERFORMANCE

The intent of this module is to supply great performance with a
reasonably feature rich API. There is no way this module can compete
with, say, using BerkeleyDB directly, and if you don't need any kind
of expiration, automatic purging, etc, that will more than likely be
much faster. If you'd like to compare the speed of some other caching
modules, have a look at
B<http://cpan.robm.fastmail.fm/cache_perf.html>.  I've included a
patch which adds Cache::BDB to the benchmark.

=head1 LOCKING

All Cache::BDB environments are opened with the DB_INIT_CDB
flag. This enables multiple-reader/single-writer locking handled
entirely by the Berkeley DB internals at either the database or
environment level. See
http://www.sleepycat.com/docs/ref/cam/intro.html for more information
on what this means for locking.

Important: it is a bad idea to share a single Cache::BDB object across
multiple processes or threads. Doing so is bound to cause you
pain. Instead, have your thread/process instantiate its own Cache::BDB
object. It is safe to have them all pointing at the same cache file.

=head1 CACHE FILES

For every new B<Cache::BDB> object, a Berkeley DB Environment is
created (or reused if it already exists). This means that even for a
single cache object, at least 4 files need to be created, three for
the environment and at least one for the actual data in the cache. Its
possible for mutliple cache database files to share a single
environment, and its also possible for multiple cache databases to
share a single database file. See the SYNOPSIS above for a quick view
of what you are likeley to find on the filesystem for a
cache. Cache::BDB uses BerkeleyDB exclusively with regard to files, so
if you have questions about whats in those files, you might
familiarize yourself further with Berkeley DB.

=head1 USAGE

=over 4

=item B<new>(%options)

=item * cache_root

Specify the top level directory to store cache and related files
in. This parameter is required. Keep in mind that B<Cache::BDB> uses a
B<BerkeleyDB> environment object so more than one file will be written
for each cache.

=item * cache_file

If you want to tell B<Cache::BDB> exactly which file to use for your
cache, specify it here. This paramater is required if you plan to use
the env_lock option and/or if you want to have multiple logical
databases (namespaces) in a single physical file. If unspecified,
B<Cach::BDB> will create its database file using the
B<namespace>. B<cache_file> should be relative to your cache_root, not
fully-qualified, i.e.

 my %options = ( cache_root => '/some/location/for/caching/',
                 cache_file => 'whatever.db',
                 namespace  => 'MyObjects');

This gives you, among other files,  /some/location/for/caching/whatever.db.
Your logical database inside of 'whatever.db' will be named with 'MyObject'.
If you were to then instantiate another Cache::BDB with the following:

 my %options = ( cache_root => '/some/location/for/caching/',
                 cache_file => 'whatever.db',
                 namespace  => 'MyOtherObjects');

You would now have two logical caches in one physical file, which is
ok, but see B<namespace> below for a better idea.

=item * namespace

Your B<namespace> tells B<Cache::BDB> where to store cache data under
the B<cache_root> if no B<cache_file> is specified or what to call the
database in the multi-database file if B<cache_file> is specified. It
is a required parameter. For clarity, it might be best to instantiate
B<Cache::BDB> objects like so:

 my $namespace = 'MyObjects';
 my %options = ( cache_root => "/some/location/for/caching/$namespace",
                 namespace => $namespace );

Unlike the examples given above under cache_file, this allows you to
locate a single cache type in its own directory, which gives you more
flexibility to nuke it wholesale or move things around a little.

=item * type

Cache::BDB allows you to select the type of Berkeley DB storage
mechanism to use. Your choices are Hash, Btree, and Recno. Queue isn't
supported. I haven't tested the three supported types extensively. The
default, if unspecified, is Btree, and this is probably good enough
for most applications. Note that if a cache is created as one type it
must remain that type. If you instantiate a Cache::BDB object with one
type (or use the default), and then attempt to connect to the same
cache with a newly instantiated object that uses a different type, you
will get a warning, and Cache::BDB will be nice and connect you to the
cache with its original type.

Important: up until Berkeley DB 4.4.x, it has not been possible to
shrink the physical size of a database file, which means that,
technically, your cache files will never get smaller even if you
delete everything from them. HOWEVER, with 4.4.x this functionality is
now possiblye but it will only work with the Btree type. As soon as
this is available in the BerkeleyDB.pm wrapper (soon I'm told), I'll
be releasing a version with some options to allow this. Point being,
this may be a good reason to stick with Btree.

For more info, see http://www.sleepycat.com/docs/ref/am_conf/intro.html.

=item * env_lock

If multiple databases (same or different files) are opened using the
same Berkeley DB environment, its possible to turn on environment
level locking rather than file level locking. This may be advantageous
if you have two separate but related caches. By passing in the
env_lock parameter with any true value, the environment will be
created in such a way that any databases created under its control
will all lock whenever Berkeley DB attempts a read/write lock. This
flag must be specified for every database opened under this
environment. Note: this is very untested in Cache::BDB, and I don't
know how necessary it is.

=item * default_expires_in

Time (in seconds) that cached objects should live. If set to 0,
objects never expire. See B<set> to enable a per-object value.

=item * auto_purge_interval

Time (in seconds) that the cached objects will be purged by one or
both of the B<auto_purge> types (get/set). If set to 0, auto purge is
disabled. Note, of course, that objects won't actually be purged until
some event actually takes place that will call purge (set or get), so
if this is set to 300 but no gets or sets are called for more than 300
seconds, the items haven't actually been purged yet.

=item * auto_purge_on_set

If this item is true and B<auto_purge_interval> is greater than 0,
calling the B<set> method will first purge any expired records from
the cache.

=item * auto_purge_on_get

If this item is true and B<auto_purge_interval> is greater than 0,
calling the B<get> method will first purge any expired records from
the cache.

=item * purge_on_init

If set to a true value, purge will be called before the constructor returns.

=item * purge_on_destroy

If set to a true value, purge will be called before the object goes
out of scope.

=item * clear_on_init

If set to a true value, clear will be called before the constructor returns.

=item * clear_on_destroy

If set to a true value, clear will be called before the object goes
out of scope.

=item * disable_compact

Disable database compactions for clear, purge, delete and remove
methods. See B<DATABASE SIZE> below for more information on database
compaction.

=item * disable_auto_purge

As a courtesy, Cache::BDB will automatically remove() any expired
cache item you get() before returning undef. This is handy if you
don't feel the need to do a lot of explicit cache purging, but if you
only want purge, remove, delete or clear to actually delete cache
items, you can disable this functionality by passing in
disable_auto_purge with any true value.

=back

=over 4

=item B<close>()

Explicitly close the connection to the cache. A good idea. Essentially
the same as undef'ing the object (explicitly calls DESTROY).

=item B<namespace>()

This read only method returns the namespace that the cache object is
currently associated with.

=item B<auto_purge_interval>($seconds)

Set/get the length of time (in seconds) that the cache object will
wait before calling one or both of the B<auto_purge> methodss. If set
to 0, automatic purging is disabled.

=item B<auto_purge_on_set>(1/0)

Enable/disable auto purge when B<set> is called.

=item B<auto_purge_on_get>(1/0)

Enable/disable auto purge when B<get> is called.

=item B<set>($key, $value, [$seconds])

Store an item ($value) with the associated $key. Time to live (in
seconds) can be optionally set with a third argument. Returns true on success.

=item B<add>($key, $value, [$seconds])

Only B<set> in the cache if the key doesn't already exist.

=item B<replace>($key, $value, [$seconds])

Only B<set> in the cache if the key does exist.

=item B<get>($key)

Locate and return the data associated with $key. Returns the object
associated with $key or undef if the data doesn't exist. If
B<auto_purge_on_get> is enabled, the cache will be purged before
attempting to locate the item.

=item B<get_bulk>()

Returns a hash reference containing every unexpired item from the
cache key'ed on their cache id. This can be useful if your keys aren't
always available or if you just want to use the cache as a convenient
way to dump data in chunks.

The result looks something like this:

 my $h = $cache->get_bulk();

 # $h = { 123 => "bird and bee",
 #        456 => "monkeys with sticks",
 #        789 => "take whats mine",
 #      };

=item B<remove>($key)

Removes the cache element specified by $key if it exists. Returns true
for success.

=item B<delete>($key)

Same as remove()

=item B<clear>()

Completely clear out the cache and compact the underlying
database. Returns the number of cached items removed.

=item B<count>()

Returns the number of items in the cache.

=item B<size>()

Return the size (in bytes) of all the cached items. This call relies
on the availability of B<Devel::Size>. If its not found, you'll get a
warning and size() will simply return 0. Currently the size is
calculated every time this is called by using
B<Devel::Size::total_size>, so it may be expensive for large
caches. In the future size-aware options and functionality may be
available, but for now you'll need to implement this outside of
Cache::BDB if you need it.

=item B<purge>()

Purge expired items from the cache. Returns the number of items purged.

=item B<is_expired>($key)

Returns true if the data pointed to by $key is expired based on its
stored expiration time. Returns false if the data isn't expired *or* if the
data doesn't exist.

=back

=head1 DATABASE SIZE

(See http://www.sleepycat.com/docs/ref/am_misc/diskspace.html)

Before Berkeley DB release 4.4 it was not possible to return freed
space in a database file. This means that no matter how many items you
delete, your file will still retain its size, and continue to grow as
you add more items. The only way to get the file size back down was to
dump the database to a file and reload it into a new database
file. This may or may not be a problem for your application, but keep
in mind that your cache will continue to get bigger and, for example,
your operating system may have a maximum file size limit.

In 4.4, Sleepycat introduced the ability to free unused
space. BerkeleyDB 0.29 exposes this functionality in the perl
wrapper. If you are using these versions or better and have chosen the
Btree database type (the default for Cache::BDB), your caches will
automatically be compacted when items are purged, removed/deleted, or
if clear is called. You can disable the automatic compaction of cache
files by initializing your Cache::BDB object with the disable_compact
parameter set to any true value. In my tests so far, however, database
compaction does not appear to affect performance significantly, and
may save you from a headache down the road.

=head1 AUTHOR

Josh Rotenberg, C<< <joshrotenberg at gmail.com> >>

=head1 TODO

* Make data storage scheme configurable (Storable, YAML, Data::Dumper,
  or callback based)

* Split storage between meta and data for faster operations on meta data.

* Add some size/count aware features.

* Create some examples.

* Fix fork()'ing tests.

=head1 BUGS

Please report any bugs or feature requests to C<bug-cache-bdb at
rt.cpan.org>, or through the web interface at
L<http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Cache-BDB>.  I will
be notified, and then you'll automatically be notified of progress on
your bug as I make changes.

=head1 SUPPORT

You can find documentation for this module with the perldoc command.

    perldoc Cache::BDB

You can also look for information at:

=over 4

=item * AnnoCPAN: Annotated CPAN documentation

L<http://annocpan.org/dist/Cache-BDB>

=item * CPAN Ratings

L<http://cpanratings.perl.org/d/Cache-BDB>

=item * RT: CPAN's request tracker

L<http://rt.cpan.org/NoAuth/Bugs.html?Dist=Cache-BDB>

=item * Search CPAN

L<http://search.cpan.org/dist/Cache-BDB>

=back

=head1 SEE ALSO

BerkeleyDB

=head1 ACKNOWLEDGEMENTS

Baldur Kristinsson
Sandy Jensen

=head1 COPYRIGHT & LICENSE

Copyright 2006 Josh Rotenberg, all rights reserved.

This program is free software; you can redistribute it and/or modify it
under the same terms as Perl itself.

=cut