| | 1 | ''Part of DjangoSpecifications'' |
| | 2 | |
| | 3 | = Threading improvements in Django = |
| | 4 | |
| | 5 | According to tickets #5632, #6950 and discussions http://groups.google.com/group/django-users/browse_frm/thread/a7d42475b66530bd, http://groups.google.com/group/django-developers/browse_thread/thread/fbcfa88c997d1bb3, at least the following components of Django are not entirely thread-safe: |
| | 6 | * django.template.loader |
| | 7 | * django.db.models |
| | 8 | * django.contrib.sessions |
| | 9 | |
| | 10 | This specification outlines the changes that need to be implemented to solve these issues. |
| | 11 | |
| | 12 | A related task is to identify other components not mentioned here that have threading issues. |
| | 13 | |
| | 14 | == Proposal == |
| | 15 | |
| | 16 | Instead of ad-hoc solutions like the one proposed in #5632, there should be a locking module that can be reused. |
| | 17 | |
| | 18 | Four types of locking primitives could be implemented: |
| | 19 | * Django-wide global locks |
| | 20 | * module-level locks |
| | 21 | * class-level locks |
| | 22 | * function-level locks |
| | 23 | |
| | 24 | 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. |
| | 25 | Template loader could use either a function-level lock or a module-level lock. |