Version 4 (modified by anonymous, 11 years ago) (diff)


Part of DjangoSpecifications

Threading improvements in Django

According to tickets #5632, #6950 and discussions,, at least the following components of Django are not entirely thread-safe:

  • django.template.loader
  • django.db.models
  • django.contrib.sessions

This specification outlines the changes that need to be implemented to solve these issues.

A related task is to identify other components not mentioned here that have threading issues.


Instead of ad-hoc solutions like the one proposed in #5632, there should be a locking module that can be reused.

Five types of locking primitives could be implemented:

  • Django-wide global locks
  • module-level locks
  • class-level locks
  • instance-level locks
  • function-level locks

I don't see any use for a Django-wide lock. Module-level lock is needed for sessions. Class-level locks seem appropriate for models. Template loader can use a function-level lock.

FIXME: module and class level locks missing. The implementation is a modified copy of and should perhaps reside in django.utils.locking:

from django.utils._threading_local import RLock

def getattr_(obj, name, default_thunk):
    "Similar to .setdefault in dictionaries."
        return getattr(obj, name)
    except AttributeError:
        default = default_thunk()
        setattr(obj, name, default)
        return default

def locked(func, *args, **kw):
   lock = getattr_(func, "__lock", RLock)
       result = func(*args, **kw)
   return result

Database model locking

All functions that have .alters_data = True should be wrapped with a locked block.


Once older python version support will be dropped in distant future, locking should be implemented with with:

Back to Top