On Fri, Sep 08, 2000 at 03:46:25PM +0100, Tim Sweetman wrote:
> This can be an extremely powerful approach to speeding up web
> applications. We use a similar module which ended up fairly large - it
> takes a method name & arguments, rather than an SQL string, meaning that
> you can cache the result of operations other than SQL queries. It's also
> grown several other enhancements: a mutual-exclusion-and-backoff
> algorithm, so if one process is looking for the answer, others wait for
> it rather than performing the same query at the same time, and several
> ways to expire results that have become outdated (specifying lifetime,
> or via timestamp files that get touched when major changes happen)
That sure sounds powerful!
> The one thing I'd advise is: BE VERY CAREFUL WITH RACE CONDITIONS. You
> can easily end up with something that will, in an unusual case, store
> garbled data. I think you'd need to either use flock(), or write to
> files then rename them, since rename is an atomic operation - and I
> don't know how well that works under OSs other than UNIXes.
I use the latter approach: write to a temp name, then rename. I really
think this should be safe anywhere, I don't think any OS would be broken
enough to make a rename non atomic, and let other processes read garbled
stuff when the original file was written to and closed.
> Many CPAN things that do this sort of thing use tied hashes, which
> (mostly, at least) won't work in a multi-process environment because
> they don't handle concurrent reads & writes.
I really prefer Storable or something like it, for this application. So
each cached value is a file, and we can use the filesystem and its
lastmod metadata, and standard tools like find or File::Find (or
whatever its name is) to clean up.
--
Roger Espel Llima, [EMAIL PROTECTED]
http://www.iagora.com/~espel/index.html
