search

Jdesk / memcached

Automatically exported from code.google.com/p/memcached
0 stars 0 forks source link

Objects do not move to top of LRU when touched #189

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Hi,

I'm using v1.4.5 installed on Fedora. This could be something basic I don't 
understand and not a bug - if so, I'm sorry.

If I set() a new object with expiry time of X , the object expires regardless 
if BEFORE X elapsed I "touch" it as explained in "Touching keys with add" @ 
http://code.google.com/p/memcached/wiki/NewProgrammingTricks.

My expectation was that the "touch" will reset the expiration time of the 
object back to X (from the time of "touch") but it doesn't. If "touching" 
doesn't reset the expiration time to the original value X then I don't 
understand what do you mean by "add will actually bump a value to the front of 
memcached's LRU if it already exists.". What difference does it make for me if 
the object is at the top or bottom of LRU if the expiration time is still the 
same?

This happened to me using two different clients (a perl client and .NET client) 
so if it is a bug I don't think it has to do with the clients.

Many thanks, 
Yossi.

Original issue reported on code.google.com by YoC....@gmail.com on 4 Mar 2011 at 2:15

GoogleCodeExporter commented 9 years ago 
Add will _not_ change the original item in the cache (flags, expiry time, cas 
etc). It will however change the objects position of the list of objects to 
evict if someone tries to store additional objects when all of the memory is 
used. Getting the object would have the same effect, but it would require all 
of the data for the object to be transferred back to the client. Personally I 
would think that calling a cas with an illegal value would be a better 
alternative, because then you would not end up in a situation where add 
succeeds and you have a bogus item in you cache.

Original comment by trond.no...@gmail.com on 4 Mar 2011 at 2:47