Object creation/locking issue

Brad Fitzpatrick brad@danga.com
Wed, 18 Feb 2004 09:17:10 -0800 (PST)


Tom,

> 1. Requirement for blocking on access to a key:
>
> Here is a scenario -- taking usage out of the pure web-interface
> implementation:
>
> Supposing I wish to cache objects that are computationally expensive to
> generate, ie to the order of a few seconds up to 15 minutes.  I can have
> unique keys, put them in namespaces, and otherwise identify them, but I
> really do not want to be generating them in parallel, as that chews up
> resources.
>
> So, if a process discovers that the object is not in the cache, it needs
> to 'lock' that key before going off to generate the object, so that any
> other process looking up that object are blocked until it has been put
> in to the cache.  Clearly, the block would have to be dropped if that
> other process dies (or unlocks the key) without generating the object.

LiveJournal has the same issue.  (where we don't want to compute something
expensive in parallel).  Since we use MySQL, we use MySQL's GET_LOCK() and
RELEASE_LOCK().  Our code often looks like:

object = memcache_get
if (object) objeect
GET_LOCK("making_object_name")
if (object) {
   # maybe it was made in the meantime
   RELEASE_LOCK()
   return object;
}
# make object
....
memcache_set(object)
RELEASE_LOCK()
return object

What database are you using?

This is probably a common enough requirement that we could push it into
memcached.  Any volunteers?  :)


> 2. Caching on mfu, creation expense and time
>
> Having a cache capacity limit that drops objects based on their
> popularity as well as age would be a strong advantage when there are

Memcached currently drops the items that were accessed the longest time
ago.  (well, in each size class, but if you keep your size classes
balanced, it's effectively the same thing.)


> limited memory resources for caching, or under-utilised objects are
> stored.  Better still, storing a 'construction expense' value with an
> object would permit relatively cheap objects to be purged in order to
> maintain the most expensive cache elements longer.

Could work.  The details would need to be worked out, though.  I'm not
sure how useful it'd end up being.

So you'd do some weighted combination of size, access pattern, and
construction expense to discard objects?  Could get painful.


- Brad