title: memcache.get returns wrong object (Celery, Django)
body: <p>Here is what we have currently:</p>
  
  <ol>
  <li>we're trying to get cached django model instance, cache key includes name of model and instance id. Django's standard memcached backend is used. This procedure is a part of common procedure used very widely, not only in celery.</li>
  <li>sometimes(randomly and/or very rarely) cache.get(key) returns wrong object: either int or different model instance, even same-model-different-id case appeared. We catch this by checking correspondence of model name &amp; id and cache key. </li>
  <li>bug appears only in context of three of our celery tasks, never reproduces in python shell or other celery tasks. <em>UPD: appears under long-running CPU-RAM intensive tasks only</em> </li>
  <li>cache stores correct value (we checked that manually at the moment the bug just appeared)</li>
  <li>calling same task again with same arguments might don't reproduce the issue, although probability is much higher, so bug appearances tend to "group" in same period of time</li>
  <li>restarting celery solves the issue for the random period of time (minutes - weeks)</li>
  <li>*NEW* this isn't connected with memory overflow. We always have at least 2Gb free RAM when this happens.</li>
  <li>*NEW* we have <code>cache_instance = cache.get_cache("cache_entry")</code> in static code. During investigation, I found that at the moment the bug happens <code>cache_instance.get(key)</code> returns wrong value, although <code>get_cache("cache_entry").get(key)</code> on the next line returns correct one. This means either bug disappears too quickly or for some reason cache_instance object got corrupted.
  Isn't cache instance object returned by django's cache thread safe?</li>
  <li>*NEW* we logged very strange case: as another wrong object from cache, we got model instance w/o id set. This means, the instance was never saved to DB therefore couldn't be cached. (I hope)</li>
  <li>*NEW* At least one <code>MemoryError</code> was logged these days</li>
  </ol>
  
  <p>I know, all of this sounds like some sort of magic.. And really, any ideas how that's possible or how to debug this would be very appreciated.</p>
  
  <p>PS: My current assumption is that this is connected with multiprocessing: as soon as cache instance is created in static code and before Worker process fork this would lead to all workers sharing same socket (Does it sound plausibly?)</p>