At 22:23 Uhr -0500 10.3.2001, DeWitt Clinton wrote:
>On Sat, Mar 10, 2001 at 04:35:02PM -0800, Perrin Harkins wrote:
> > Christian Jaeger wrote:
>> > Yes, it uses a separate file for each variable. This way also locking
>> > is solved, each variable has it's own file lock.
>>
>> You should take a look at DeWitt Clinton's Cache::FileCache module,
>> announced on this list. It might make sense to merge your work into
>> that module, which is the next generation of the popular File::Cache
>> module.
>
>Yes! I'm actively looking for additional developers for the Perl
>Cache project. I'd love new implementations of the Cache interface.
>Cache::BerkeleyDBCache would be wonderful. Check out:
>
> http://sourceforge.net/projects/perl-cache/
>
>For what it is worth, I don't explicitly lock. I do atomic writes
>instead, and have yet to hear anyone report a problem in the year the
>code has been public.
I've looked at Cache::FileCache now and think it's (currently) not
possible to use for IPC::FsSharevars:
I really miss locking capabilities. Imagine a script that reads a
value at the beginning of a request and writes it back at the end of
the request. If it's not locked during this time, another instance
can read the same value and then write another change back which is
then overwritten by the first instance.
IPC::FsSharevars even goes one step further: instead of locking
everything for a particular session, it only locks individual
variables. So you can say "I use the variables $foo and %bar from
session 12345 and will write %bar back", in which case %bar of
session 12345 is locked until it is written back, while $foo and @baz
are still unlocked and may be read (and written) by other instances.
:-) Such behaviour is useful if you have framesets where a browser
may request several frames of the same session in parallel (you can
see an example on http://testwww.ethz.ch, click on 'Suche' then on
the submit button, the two appearing frames are executed in parallel
and both access different session variables), or for handling session
independant (global) data.
One thing to be careful about in such situations is dead locking.
IPC::FsSharevars prevents dead locks by getting all needed locks at
the same time (this is done by first requesting a general session
lock and then trying to lock all needed variable container files - if
it fails, the session lock is freed again and the process waits for a
unix signal indicating a change in the locking states). Getting all
locks at the same time is more efficient than getting locks always in
the same order.
BTW some questions/suggestions for DeWitt:
- why don't you use 'real' constants for $SUCCESS and the like? (use constant)
- you probably should either append the userid of the process to
/tmp/FileCache or make this folder globally writeable (and set the
sticky flag). Otherwise other users get a permission error.
- why don't you use Storable.pm? It should be much faster than Data::Dumper
>I have some preliminary benchmark code -- only good for relative
>benchmarking, but it is a start. I'd be happy to post the results
>here if people are interested.
Could you send me the code?, then I'll look into benchmarking my module too.
