Tickets :: Comment on [#13085] Use memcache instead of distributed hashtable in $conf[cache][driver]

* Your Email Address
* Spam protection	Enter the letters below: . ..___ __.. .._. \ /[__ (__ \|__\| \| \/ [___.__)\| \|_\|_
Comment	>> But in that case it is still a waste of cache, to keep entries around >> for the configured default value for the cache lifetime, while we >> already know it will not be used anymore after $lifetime seconds in >> the future. > > Not for memcache. Again, you don't need to worry about expiration > for memcache since old entries will automatically be pruned. Dealing > with GC is just adding unnecessary overhead. > > And for many purposes, it is advantageous to use the cache if it > exists, regardless of lifetime. You might want to limit the size of > your file-based cache by providing a max lifetime ... not because the > data has an expiration date but simply because you want to limit the > number of entries. But the brilliance of memcache is that it makes > this part of the calculus obsolete: the data is available until you > run out of space. > >> We already know that at the time of setting the cache >> value, so it seems a waste not to use that knowledge. > > Except, theoretically, you could set a cache value and then try to > grab it later in two different locations ... and one of those > locations may have a different (or no) lifetime argument. So it is > not that simple. > > All this being said... I believe the issue here is simply that the > Horde_Hashtable driver doesn't currently honor the $lifetime > parameter in get(): > > /** > * NOTE: This driver ignores the lifetime argument. > */ > public function get($key, $lifetime = 0) > { > return $this->_hash->get($this->_params['prefix'] . $key); > } > > Looks like that needs to be written (exists() also).
Attachment
Watch this ticket

Saved Queries