On Mon, 2004-12-13 at 12:58 -0700, Tim Pushor wrote: > For example, what I need to do (at a high level) is be able to add > entries to the cache with a minimum TTL, and be able to have the ability > to reset the TTL on individual entries as need be.
Anything with individual TTL settings per item will let you do this. > >In what way? BerkeleyDB can handle tremendous amounts of data, and the > >locking is more efficient than what IPC::Shareable uses. > > > > > > > Perhaps - I just think that there has to be a more efficient way of > sharing data between processes than writing it to disk. It doesn't normally go to disk with BerkeleyDB. There's a shared memory cache. Even things that just use the filesystem are really not going to disk on Linux, since they are effectively using the VM system as shared memory. > The module I > wrote was for a busy community type site where all access was > authenticated, so I spread the data across multiple db's to reduce lock > contention. Page-level locking would probably work better than that, but in my experience I never found the file-level locking in BerkeleyDB's simple mode to be an issue. > To really be honest, I have never really used shared memory > much (in any programming language) so I don't really understand the main > issues - but I thought locking (in the perl module) was done with > semaphores... I don't know how BerkeleyDB implements it, but it's in the C code, not in the Perl code. The real problem with shared memory things like IPC::Shareable is that they have to serialize and de-serialize your entire data structure using Storable every time you read or write it. They have no way to address individual entries. The fast modules handle entries individually. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
