Django Transactions: Past, Present, and Future
summary
Advocates switching Django apps to PostgreSQL and using the built-in atomic blocks for per-view commits, warns that long transactions hold locks and that PG restore runs inside a single transaction so Postgres has no rollback buffer, recommends enabling serializable (Postgres 9.1+) as a default to catch subtle races and to handle serialization failures by retrying the transaction, describes Xact and savepoint quirks, and says avoid leaving transactions open or calling external services inside them.
AI-written summary · about
chapters (26)
- 0:00Start
- 2:35What is a transaction?
- 4:06The good news...
- 5:00Sessions and transactions.
- 5:43A brief history of Django transactions.
- 6:49Transaction Middleware!
- 8:38Break out the decorators!
- 13:38Batch the writes together.
- 14:19Keep transactions short.
- 16:02Feeling isolated?
- 16:34Isolation Modes.
- 18:38READ COMMITTED, redux.
- 19:10REPEATABLE READ
- 20:53What happens?
- 21:25What do we do then?
- 23:41SERIALIZABLE.
- 25:07Example of write skew.
- 25:36Oops.
- 26:11SERIALIZABLE prevents this
- 27:08My advice? Use it.
- 27:49Accept or reject?
- 28:35Setting by default.
- 28:52Some exceptions.
- 30:47PostgreSQL detects deadlocks.
- 31:26Avoiding deadlocks.
- 31:57INSERT over UPDATE.
related talks
28mPessimism, optimism, realism and Django database concurrency
21mDjango and PostgreSQL: An Even-Closer Union
33mPeaceful Django Migrations with Efe Öge
37mDistributed SQL Transactions
23mDjango with PostgreSQL superpowers
41mConcurrency, Scalability and Transactions -- Myths and Surprises
16mTransactionality Explained
30mMulti-tenancy strategies with Django+PostgreSQL