Am 22.10.2005 um 15:51 schrieb Stephen Deasey:
On 10/22/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
Am 21.10.2005 um 15:19 schrieb Vlad Seryakov:
Looks okay, API has changed but if we accept it, i suppose onetime
code change is acceptable
What about timed cache? I miss this (for us) important feature.
The existing implementation doesn't make a lot of sense to me. You
can create either a size limited cache, OR a time based cache. A time
based cache has it's entries flushed based on the mtime, i.e. only
when they're unused. This means popular entries will never be
flushed.
What you really want is for entries to have a max cache lifetime (ADP
pages), possibly different for each entry (DNS lookups).
OK. This is true, indded.
Why passing the cacheTable over ClientData?
That's just because I implemented this as a module so it could be
tested easily without patching. A merged version would add a slot to
the NsServer structure.
OK. This is clear.
Why not creating caches during server lifetime instead of only
at startup?
Locking overhead. The current implementation doesn't lock the caches
when for example the stats command is run, which could have the cache
deleted out from under it, causing a crash.
I did try a couple of ways to enable safe cache creation at runtime,
including reference counting of the caches themselves. It just seemed
over engineered.
Do you have a situation in mind where caches should be created at
runtime?
Oh yes... We have a database lib (Codebase) which is fast, but some
of the
things we did there take time. Hence, I use the cache module to keep
those
difficult computations in a timed-cache. Now, I have attached a cache to
each opened database. The databases can be opened for read/write
(single writer
multiple readers) by any thread during the runtime. I do not want to
open
all those db's on the filesystem. For example, our backup index may
consists
of 100's of tiny databases. I can't just open them all at startup.
Oh yes: a database is just a handful of files: datafile, index file,
blob file.
Hm... to be ultimately useful, it would need to be dynamic, I'm afraid.
OTOH, you need not make it 100% dynamic. You can just create caches, but
never destroy them, for example. In our app, the name of the cache is
bound to a file-name (i.e. directory where db files live). This does not
change over lifetime.
Cheers
Zoran
