expiry

[Larry Leszczynski]

On Fri, 26 May 2006, Michael Burns wrote:
>
> On 26-May-06, at 11:49 AM, Torsten Foertsch wrote:
>
>> On Friday 26 May 2006 13:21, Joshua Thijssen wrote:
>>> When I add an item to the memcache and use an expiry-timestamp, it will
>>> expire, no matter how many times the key is read in the remaing time. Is
>>> it possible to create an item with a expiry-timestamp (an relative
>>> value, say 60seconds), which gets reset each time the item is read so
>>> so the item would stay in the cache until it's not read for a long time
>>> or when we remove it.
>> 
>> I have posted a patch some time ago (~april) that beside other things 
>> includes
>> a way to make expiry times relative to the last access. If you cannot find 
>> it
>> I'll send you as private mail.
>
> Quick question re: this complex expiry issue:
>
> What would you gain beyond using existing memcached settings to set your 
> expiry-timestamp and ensuring you have enough RAM so that the built-in LRU 
> mechanism can deal with your keys in its own way?
>
> Seems like this kind of patch just adds complexity to a feature of memcached 
> that already exists intrinsically ... unless I'm missing something ...

I agree with Michael here, it sounds like the intent is to twist expiry to 
implement some different kind of LRU algorithm.  The expiry timestamp is a 
way to indicate how long you think a piece of cached data will remain 
valid, without checking the master copy to make sure.  If you're setting 
expiry for 60 seconds, but then continue to use the cached copy for a week 
because it is getting touched frequently, then why not set the expiry for 
a week in the first place?  If you set the expiry for a week but the data 
does not get touched in the mean time, memcached's LRU algorithm will 
clean it up at some point anyway, just like it should.


Larry