As discussed on Twitter following David Seddon's blog post.
transaction.atomic() guarantees the wrapped database operations is *atomic* - at the end of its wrapped block, operations within that block will all be applied, or all rolled back. In some situations it's also useful to guarantee that the wrapped operations are *durable* - at the end of the wrapped block, all operations have definitely been committed. atomic() doesn't guarantee this at the moment since its use may be wrapped by *another* atomic() higher in the stack, delaying the commit.
David Seddon's technique to guarantee durability is to wrap atomic() to first check if an atomic() is already active for the current connection (in other words, connection.get_autocommit() returns False), and raise an error if so.
On Twitter, Ian Foote suggested adding a durable flag to atomic() to add this behaviour to Django, to which Aymeric Augustin said it sounds like a good idea.
In 3828879e: