On 28/11/11 21:26, Asher Feldman wrote:
For memcache objects that can be grouped together into an "ok to use if a bit stale" bucket (such as all kinds of stats), there is also the possibility of lazy async regeneration.
Data is stored in memcache with a fuzzy expire time, i..e { data:foo, stale:$now+15min } and a cache ttl of forever. When getting the key, if the time stamp inside marks the data as stale, you can 1) attempt to obtain a exclusive (acq4me) lock from poolcounter. If immediately successful, launch an async job to regenerate the cache (while holding the lock) but continue the request with stale data. In all other cases, just use the stale data. Mainly useful if the regeneration work is hideously expensive, such that you wouldn't want clients blocking on even a single cache regen (as is the behavior with poolcounter as deployed for the parser cache.)
I see you looked at the poolcounter code :) Yes, it would be usefult to have a class handling that kind of that, which would store data valid for a known time (usually a guess) with a slightly longer expiry, packed with a timestamp. And if it was overdue, launch an update protected with an acq4any with 0 queue. I hadn't considered showing "stale" data for that first hit, but could be easily done through DeferredUpdates. You only need to be careful not to be reentrant to the same key, since you might deadlock (although with a 0-queue that's unlikely).