view release on metacpan or  search on metacpan

lib/Cache/RamDisk.pm  view on Meta::CPAN

                    'Keys'   => { 'fie' => 50,
                                  'foe' => 200,
                                  'fum' => 4000 },
                    'User'   => 'apache',
                    'Group'  => 'apache' } );

Content handler code:

   use MyApp::Fie;

   my $fie = MyApp::Fie->new (12345);
   print $fie->{'some_field'};


Object code:

   package MyApp::Fie;
   use Cache::RamDisk;

   sub new {
      my ($class, $id) = @_;
      my $c = Cache::RamDisk->new ('/tmp/rd', CACHE_LRU);
      my $self = $c->get({'fie' => $id})->{'fie'}->{$id} || do {
         # perform some db logics
         $self = $sth->fetchrow_hashref;
         bless $self, $class;
         $c->put({'fie' => { $id => $self } });
      }
      $self;
   }


Later on in a cgi script:

   use CGI qw(:html);
   use Cache::RamDisk::Functions;
   [...]
   my $s = cache_status ('/tmp/rd');
   [...]
   print "Number of items for 'fie': ".$s->key_stat('fie'), br;


On application shutdown:

   cache_remove ('/tmp/rd');


=head1 DESCRIPTION

I<Note: 'rd' is from now on in this document an abbreviation for 'ramdisk' or 'RAM Disk' or however you prefer
to write or exclaim that herewith specified thing.>

Cache::RamDisk provides multi-process applications with a means of sharing Perl objects between the
processes while trying to avoid the inconveniences inherent to other IPC tools:

1. Message queues are extremely fast, but extremely limited too.

2. Shared memory is perhaps even faster, but it came out for me to be an at least hairy problem
trying to store several references all in one segment.

3. Sockets are reliable, but require a second communication endpoint and yet another server process.

But a file is a file is a file.

The package collects as much ramdisks to a bundle as possible and necessary to hold the required user space,
depending on the respective parameters under which the system's individual kernel had been compiled.
The system user and group who owns the cache can be specified for the whole rd bunch, say cache.


=head2 Cache Types

The package provides three ways of cacheing policy. The desired type can be submitted to the individual
object constructor with one of the following values:

=head3 CACHE_LRU

Forces the accessing object methods to treat the cache under B<L>ast B<R>ecently B<U>sed aspects: an existent
object will be delivered, and the respective index entry moves to the top. Values from the 'Keys' reference
in the latest call to C<install()> define the B<maximum number of objects> for the respective key. If the index
list is full, its last line will be C<pop()>ped and the new entry C<unshift()>ed.

=head3 CACHE_TIMED

All accesses from this object to the cache treat the value for each cache key as B<maximum age in seconds>
that cache objects belonging to the key are allowed to reach. "Stale" objects will not be delivered,
but removed instead. (The decision whether to deliver or remove happens on every C<get()> request. There
may a thread be born some day.)

=head3 CACHE_DEFAULT

A fallback policy by which you may use parts of your cache as a convenient substitute for SysV shared
memory. Values set for the cache keys are ignored - which means that you will have
to invalidate objects on this type of cache "by hand". Indexes are being kept up to date by simple
C<unshift()>s and C<splice()>s. B<Note: the invalidate() method is not part of v0.1.2!>


=head1 REQUIRES

Perl B<5.6.1> on a Linux/ Unix System containing the following binaries:

   chown, mkdir, mke2fs, mount, umount

The package uses these Perl modules available from CPAN:

   IPC::Shareable
   IPC::SysV
   Filesys::Df
   Filesys::Statvfs
   File::stat
   Fcntl
   Symbol
   Class::Struct
   POSIX


=head1 EXPORTS

   CACHE_DEFAULT, CACHE_LRU, CACHE_TIMED

=head1 METHODS