Package: antidogpiling
This package provides a generic implementation and Django specific cache backends for anti-dogpiled caching. Django 1.2 and later are supported.Dogpiling is the effect of everyone rushing to renew a value that has timed out in a cache, for as long as a new value has not yet been set. Anti-dogpiling tries do mitigate this by limiting how many gets to produce a new value. How the limiting is done, and what happens to everyone else, depends on the solution.The solution provided in this package serves the old value from the cache while a new one is being produced. This is achieved by introducing a soft timeout for when the value should be renewed, in addition to the regular hard timeout (for when the value is no longer in the cache). At the event of a soft timeout, the first request is responded with a cache miss, and will go on to produce a new value, while subsequent requests are responded with the value that is still cached. When a new value is ready, it simply replaces the old value, and a new soft timeout is set.In this particular implementation, as few requests as possible are let through to produce the new value, without using any locks (I have not tested using locks. Locking across servers could be tricky and undesirable. Unless letting onlyonecall through to renew a value is a hard requirement, locking might not be worth the trouble).See theBenefits and caveatssection for important details.Using the anti-dogpiled Django backendsThe anti-dogpiled Django backends are configured like Django’s own backends. See theSetting up the cachein the Django documentation for details.Django 1.2Simply set theCACHE_BACKENDsetting to point to the right module. Examples:CACHE_BACKEND = 'antidogpiling.django.memcached://127.0.0.1:11211/'
CACHE_BACKEND = 'antidogpiling.django.filebased:///var/tmp/django_cache'Django 1.3+Simply replace theBACKENDreference with the corresponding anti-dogpiled backend. An example:CACHES = {
    'default': {
        'BACKEND': 'antidogpiling.django.memcached.MemcachedCache',
        'LOCATION': '127.0.0.1:11211'.
    },
}Configuration optionsSee thecache options settingin the Django documentation on how to specify caching options.Use thehard_timeout_factoroption to control how much longer the hard timeout should be, relative to the soft timeout. The default is 8, so by default, the hard timeout is 8 times longer than the soft timeout. (The point is not to be able to specify an exact hard timeout, but to ensure that values stay in the cache for a sufficient amount of time for the anti-dogpiling to have an effect, and for unused values to eventually disappear from the cache.)Use thedefault_grace_timeoption to set the timeout (in seconds) forrenewinga value that has timed out softly. After this period, another client will be allowed to try producing a new value. The default is 60 seconds. The grace time can also be specified per call by using thegrace_timeparameter on theaddandsetmethods.An example for Django 1.3+:CACHES = {
    'default': {
        'BACKEND': 'antidogpiling.django.memcached.MemcachedCache',
        'LOCATION': '127.0.0.1:11211'.
        'OPTIONS': {
            'hard_timeout_factor': 100,
            'default_grace_time': 10,
        },
    },
}Client usageTheadd,get,set, anddeletemethods work as usual, except that the timeouts set or invalidated are the soft timeouts, instead of the hard timeouts. To affect the hard timeouts, and to not apply any anti-dogpiling, use thehard=Trueparameter on theadd,set, anddeletemethods.Note:You must usehard=Truewhen setting an integer to be used with theincranddecrmethods. Increments and decrements require the raw integer to be stored in the cache.See the caveats below for more details.Benefits and caveatsBenefits of using this packageIt provides the generic functionality, for anyone to base their own solution on.It wraps the cached data in a custom object—not in a tuple or dict or so—making it possible to cache tuples and dicts without conflicting with the internal workings of the anti-dogpiling.It supports all Django 1.2+ cache backends, without re-implementing any Django functionality.General caveatsThere is no protection against dogpiling when a value isnotin the cacheat all.Caveats in the Django backendsTheincranddecrare not anti-dogpiled due to being atomic in Memcached (at least). The anti-dogpiling would not be atomic, unless somehow implemented with locks.Note:When initializing a value for being incremented or decremented, onehasto specifyhard=Truewhen calling thesetmethod. Otherwise, the anti-dogpiling kicks in and stores a complex value which cannot be incremented (aValueErroris raised)!Theset_many,get_many, anddelete_manymethods are not anti-dogpiled, due to a combination of laziness and all the decisions that would have to be made about how to handle soft timeouts, etc.Change history1.1.3 (2012-07-19)Replaced the dynamic mixin with a regular object reference in the common
Django backend, voiding the issue with using multiple different anti-dogpiled
backends at the same time.Added dummy Django backend.1.1.2 (2012-07-02)Documentation update (no functional change)1.1.1 (2011-05-29)Added support for Django 1.3 backends1.0.1 (2011-02-02)Added manifest file for proper packaging1.0 (2011-02-02)Initial version