id,summary,reporter,owner,description,type,status,component,version,severity,resolution,keywords,cc,stage,has_patch,needs_docs,needs_tests,needs_better_patch,easy,ui_ux 30601,Extend documentation about transaction rollbacks to mention global state mutations such as caching,Sebastian Wagner,Lufafa Joshua,"ATOMIC_REQUESTS=True essentially creates nested transactions. And nested transactions might not play well with custom caching. A small example of how to use nested transactions and caching to get inconsistent data: {{{ my_mem_cache_a = ... my_mem_cache_b = ... def set_a(x): with transaction.atomic(): a = ... a.x = x a.save() my_mem_cache_a = x def set_a_b(x, y): with transaction.atomic(): set_a(x) b = ... b.y = y raise Exception() # at this point, my_mem_cache_a is out of sync with the database. b.save() my_mem_cache_b = x set_a_b(...) }}} (this example also works without transaction.atomic() ) Would be nice to add a warning to https://docs.djangoproject.com/en/2.2/topics/db/transactions/#tying-transactions-to-http-requests that ATOMIC_REQUESTS=True might be harmful, if code * uses caching * proactively updates data in the cache * makes the assumption that values are updated in the database after a transaction is finished.",Cleanup/optimization,closed,Documentation,dev,Normal,fixed,,,Ready for checkin,1,0,0,0,0,0