Changes between Initial Version and Version 1 of PylibmcSupport


Ignore:
Timestamp:
10/07/2010 02:56:29 PM (9 years ago)
Author:
otherjacob
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • PylibmcSupport

    v1 v1  
     1=== Pre-2010 ===
     2Tickets [[http://code.djangoproject.com/ticket/12427|#12427]] and [[http://code.djangoproject.com/ticket/11675|#11675]] are opened with different by related goals: get rid of cmemcache (which had gone the way of the broken-as-heck dodo) and add support for a new libmemcached wrapper pylibmc (respectively).
     3
     4
     5=== Feb 2010 ===
     6Email thread seen here begins: http://groups.google.com/group/django-developers/browse_thread/thread/4eb685ca5b305f18/
     7
     8
     9=== March 2010 ===
     10Ticket is put in for 1.2 to put use of cmemcache as FuturePendingDeprecation, while adding support for pylibmc was greenlit for 1.3
     11
     12=== October 2010 ===
     13Discussion re-started with three key points to debate:
     14
     15
     16 * Pylibmc 1.1 doesn't play that nice with mod_wsgi due to it's use of the Simplified GIL API (see: http://www.dctrwatson.com/2010/09/beware-of-using-pylibmc-1-1-and-mod_wsgi/). Probably just need to make note of it in the documentation, but it's worth noting.
     17 * The suggested use of using query-string for client-specific options and libmemcached 'behaviors' eventually leading to massive client strings, and the use of a CACHE_SETTINGS dictionary may be a better solution.
     18 * Because it bypasses the GIL, pylibmc isn't thread safe. There are a few different solutions, the most apparent being to use pylibmc's ThreadMappedPool. More info here: http://lericson.blogg.se/code/2009/september/draft-sept-20-2009.html and http://blog.sendapatch.se/2009/september/pooling-with-pylibmc-pt-2.html .
     19
     20Another post of note with regards to multithreading [ala, celery] here: http://www.dctrwatson.com/2010/09/python-thread-safe-does-not-mean-fork-safe/#more-48
Back to Top