ATOMIC_REQUESTS creates unnecessary database connections and transactions

[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?

[Aymeric Augustin]

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.