Why is using thread locals in Django bad?

I disagree entirely. TLS is extremely useful. It should be used with care, just as globals should be used with care; but saying it shouldn’t be used at all is just as ridiculous as saying globals should never be used.

For example, I store the currently active request in TLS. This makes it accessible from my logging class, without having to pass the request around through every single interface–including many that don’t care about Django at all. It lets me make log entries from anywhere in the code; the logger outputs to a database table, and if a request happens to be active when a log is made, it logs things like the active user and what was being requested.

If you don’t want one thread to have the capability of modifying another thread’s TLS data, then set your TLS up to prohibit this, which probably requires using a native TLS class. I don’t find that argument convincing, though; if an attacker can execute arbitrary Python code as your backend, your system is already fatally compromised–he could monkey patch anything to be run later as a different user, for example.

Obviously, you’ll want to clear any TLS at the end of a request; in Django, that means clearing it in process_response and process_exception in a middleware class.

Leave a Comment