Provided by: libcache-bdb-perl_0.04-2_all bug

NAME

       Cache::BDB - An object caching wrapper around BerkeleyDB

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

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
       Cache::Cache-like interface as much as possible, though it may differ here and there.

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.

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 http://cpan.robm.fastmail.fm/cache_perf.html.  I've included a patch which adds
       Cache::BDB to the benchmark.

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.

CACHE FILES

       For every new 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 multiple 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.

USAGE

       new(%options)
           ·   cache_root

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

           ·   cache_file

               If you want to tell Cache::BDB exactly which file to use for your cache, specify
               it here. This parameter 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, Cach::BDB will create its database file using the namespace.
               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
               namespace below for a better idea.

           ·   namespace

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

           ·   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.

           ·   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.

           ·   default_expires_in

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

           ·   auto_purge_interval

               Time (in seconds) that the cached objects will be purged by one or both of the
               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.

           ·   auto_purge_on_set

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

           ·   auto_purge_on_get

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

           ·   purge_on_init

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

           ·   purge_on_destroy

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

           ·   clear_on_init

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

           ·   clear_on_destroy

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

           ·   disable_compact

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

           ·   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.

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

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

       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 auto_purge methodss. If set to 0, automatic purging is disabled.

       auto_purge_on_set(1/0)
           Enable/disable auto purge when set is called.

       auto_purge_on_get(1/0)
           Enable/disable auto purge when get is called.

       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.

       add($key, $value, [$seconds])
           Only set in the cache if the key doesn't already exist.

       replace($key, $value, [$seconds])
           Only set in the cache if the key does exist.

       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 auto_purge_on_get is enabled, the cache
           will be purged before attempting to locate the item.

       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",
            #      };

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

       delete($key)
           Same as remove()

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

       count()
           Returns the number of items in the cache.

       size()
           Return the size (in bytes) of all the cached items. This call relies on the
           availability of 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
           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.

       purge()
           Purge expired items from the cache. Returns the number of items purged.

       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.

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.

AUTHOR

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

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.

BUGS

       Please report any bugs or feature requests to "bug-cache-bdb at rt.cpan.org", or through
       the web interface at <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.

SUPPORT

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

           perldoc Cache::BDB

       You can also look for information at:

       ·   AnnoCPAN: Annotated CPAN documentation

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

       ·   CPAN Ratings

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

       ·   RT: CPAN's request tracker

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

       ·   Search CPAN

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

SEE ALSO

       BerkeleyDB

ACKNOWLEDGEMENTS

       Baldur Kristinsson Sandy Jensen

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.