Opened 7 years ago

Closed 7 years ago

#23292 closed Bug (wontfix)

ATOMIC_REQUESTS creates unnecessary database connections and transactions

Reported by: ijl Owned by: nobody
Component: Uncategorized Version: 1.6
Severity: Normal Keywords: atomic_requests, database, transactions
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by ijl)

When specifying ATOMIC_REQUESTS on a database, a connection is made to the database whether or not it is used. This is due to BaseHandler.make_view_atomic wrapping the view in a transaction.atomic for each database. Each call to transaction.atomic results in opening a database connection and then opening a transaction.

Is there any interest in modifying this to acquire connections and transactions only when the ORM attempts to use that database?

Change History (2)

comment:1 Changed 7 years ago by ijl

Description: modified (diff)

comment:2 Changed 7 years ago by Aymeric Augustin

Resolution: wontfix
Status: newclosed

I'm almost sure this idea has come up before, either here or on the django-developers mailing-list, but I couldn't find a discussion in five minutes.

The main issue with delaying the creation of the transaction is that it creates action-at-a-distance. Because you entered (say) lazy_atomic, at some later point, an unrelated piece of code is going to run a BEGIN or a CREATE SAVEPOINT, and if that fails, the stack trace will be confusing. For this reason, I don't think it's a good idea to add this behavior to Django.

If you want to, my recommendation would be:

  • try to implement it externally — I suggest writing a mixin for Django's database backends (see https://github.com/carljm/django-transaction-hooks for an example of this approach)
  • if it works well, but would benefit from being maintained in Django, explain why on the django-developers mailing list.

That said, before you edited your report, it mentioned the TransactionMiddleware and multiple databases. For that use case, it may be easier to decorate views with @atomic(using='...') depending on which database connections you expect to use.

PS: apparently you noticed that you were vulnerable to data integrity bugs if you relied on the TransactionMiddleware for non-default databases ;-) That's one of the reasons why I deprecated it.

Note: See TracTickets for help on using tickets.
Back to Top