item expiration

[dormando]

hate to say it, but I almost like this alternative. We already have the 
option to disable evictions entirely. Mixing those into the cache means 
they at least need to be promoted to the head when an eviction is called.

Mixing them into general caches might tend to cause more bugs as the 
effective temporary cache size shrinks over time.

Thinking it through, I'm not actually entirely sure how priority without 
a guarantee on evictions would be of much use. if an item is that 
important, but not accessed very often, is it really that important? If 
the number of values are small, that smells more like a database summary 
table entry with its own cache than a server modification. That would be 
tolerant to any sort of cache failure (ie; upgrades). Building in minor 
guarantees is asking for pain.

-Dormando

Josef Finsel wrote:
> Dustin,
> 
> I agree that this seems to conflict with the idea of how memcache is 
> generally used. But the suggestion your making still wouldn't guarantee 
> that the item would stay in cache since it could be that there are no 
> other lower priority LRU items to be dumped.
> 
> The only way to really lock something into memcached is to set up a 
> separate server and load the important items into it and not use it for 
> the other caches.
> 
> Josef
> 
> "If you see a whole thing - it seems that it's always beautiful. 
> Planets, lives... But up close a world's all dirt and rocks. And day to 
> day, life's a hard job, you get tired, you lose the pattern."
> Ursula K. Le Guin
> 
> On Wed, Jun 11, 2008 at 12:30 PM, Dustin Sallings <dustin at spy.net 
> <mailto:dustin at spy.net>> wrote:
> 
> 
>      IMO, the idea does conflict a bit with the idea of a cache, at
>     least as I understand it.
> 
>      Implementation-wise, it seems like another command to flag an
>     existing record as one that should specify LRU  priority.
> 
>      I can imagine if you have items you want to not be removed by LRU
>     that you perhaps also have items you consider cheaper than others
>     and would prefer these other items discarded before more expensive
>     items to recreate.
> 
>      Likewise, it doesn't unreasonable to have items you want to expire
>     at a particular point in time, but not before it.
> 
>      If you can imagine communicating a cost of invalidation to
>     memcached, you could see how careful use of such a thing could
>     potentially make for more efficient systems.  For a finite list of
>     priorities, it could be inplemented quite easily and efficiently.
> 
>     -- 
>     Dustin Sallings (mobile)
> 
> 
>     On Jun 11, 2008, at 5:48, "Reinis Rozitis" <roze at roze.lv
>     <mailto:roze at roze.lv>> wrote:
> 
>             RR the patch you pointed to sounds exactly what I'm looking
>             for. If  you would not mind posting your latest version
>             patch please.
> 
> 
>         This is not my patch (all credits go to Paul G) but just a bit
>         tweaked to apply for current (1.2.5) release.
>         http://roze.lv/memcached-permitems.patch
> 
> 
>         As to answering few of Brads comments:
> 
>         I think Paul wanted to show just some quick working concept of
>         the feature which in real world situations is pretty usefull
>         rather than push the patch directly into source. Ram is cheap,
>         but in some cases you still can't deploy enough to satisfy all
>         the web-coder needs so instead of cycling the cache all the time
>         give some logic and decision possibilities to (client) software
>         which data is more important.
> 
>         It sure  needs love to cope with the current code-style, but the
>         question is whether the current developers are fine with the
>         idea/option at all.
> 
>         rr
> 
>