[Django] #34359: Support disabling global thread_sensitive flag for Async ORM

3 views
Skip to first unread message

Django

unread,
Feb 21, 2023, 2:36:24 AM2/21/23
to django-...@googlegroups.com
#34359: Support disabling global thread_sensitive flag for Async ORM
-----------------------------------------+------------------------
Reporter: Jameel A. | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 4.1
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
Apologies if this has been discussed before, but I couldn't find a related
issue.

The way the Async ORM interface is currently implemented is by simply
introducing new `a`-prefixed methods that wrap the original `QuerySet`
methods in `sync_to_async`. On the surface this is a simple, slightly
suboptimal, way of implementing `asyncio` support.

Under the surface, though, there be dragons. With `asgiref` enabling the
`thread_sensitive` by default, what actually happens is ''ALL'' uses of
`sync_to_async` get queued onto a single thread. This can have disastrous
performance implications as we've seen in production (especially when used
with native `async` code).

While `thread_sensitive` is ''safer'' as mentioned in the docs, it's not
always necessary. For example, when using Postgres, the `psycopg` database
driver is thread-safe and appears to work fine with the `thread_sensitive`
flag disabled.

The issue here is not whether `thread_sensitive` should be `True` by
default, but rather there should be a way to disable it when the user
''knows'' it's safe to do so. In particular, for the async ORM and async
cache interfaces, it would be wonderful to configure thread sensitivity
via a setting.

--
Ticket URL: <https://code.djangoproject.com/ticket/34359>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Reply all
Reply to author
Forward
0 new messages