Re: [naviserver-devel] ns_cache

[Zoran V. <zv...@ar...>]

Am 22.10.2005 um 15:51 schrieb Stephen Deasey:

> On 10/22/05, Zoran Vasiljevic <zv...@ar...> 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