Is storing data in "thread local storage" in a Django application safe, in cases of concurrent requests?

Question

I have seen at many places that using thread local storage to store any data in Django application is not a good practice. But this is the only way I could store my request object. I need to store it because my application has a complex structure. And I can't keep on passing the request object at each function call or class intialization.

I need the cookies and headers from my request object, to be passed to some api calls I'm making at different places in the application.

I'm using this for reference: https://blndxp.wordpress.com/2016/03/04/django-get-current-user-anywhere-in-your-code-using-a-middleware/

So I'm using a middleware, as mentioned in the reference. And, this is how request is stored

from threading import local
_thread_locals = local()
_thread_locals.request = request

And, this is how data is fetched:

getattr(_thread_locals, "request", None)

So does are the data stored in the threads local to that particular request ? Or if another request takes place at the same time, does both of them use the same data ?(Which is certainly not what i want)

Or is there any new way of dealing with this old problem(storing request object globally)

Note: I'm also using async at places in my Django application(If that matters).

Answer 1

Yes, using thread-local storage in Django is safe.

Django uses one thread to handle each request. Django also uses thread-local data itself, for instance for storing the currently activated locale. While appservers such as Gunicorn and uwsgi can be configured to utilize multiple threads, each request will still be handled by a single thread.

However, there have been conflicting opinions on whether using thread-locals is an elegant and well-designed solution. The reasons against using thread-locals boil down to the same reasons why global variables are considered bad practice. This answer discusses a number of them.

Still, storing the request object in thread-local data has become a widely used pattern in the Django community. There is even an app Django-CRUM that contains a CurrentRequestUserMiddleware class and the functions get_current_user() and get_current_request().

Note that as of version 3.0, Django has started to implement asynchronous support. I'm not sure what its implications are for apps like Django-CRUM. For the foreseeable future, however, thread-locals can safely be used with Django.