Pessimism, optimism, realism and Django database concurrency
summary
Describes concrete fixes for DB concurrency in Django: use SELECT ... FOR UPDATE for pessimistic locking, or an optimistic scheme with a version field and retries; notes Django needs packages for optimistic locking and that using F() expressions makes version increments race-safe because the DB evaluates them under lock. Shows Oracle and Django behaviour where updates and even creates block, cites a real system hitting >5,000 transactions/sec, and recommends finer lock granularity and moving noncritical writes out of the transaction rather than adding Redis locks.
AI-written summary · about
chapters (16)
- 0:00Introduction and background
- 1:09Real-world concurrency challenges
- 3:16Race conditions and lost updates
- 8:36Shared database concurrency
- 10:04Pessimistic locking in Django
- 11:07Optimistic locking explained
- 12:55Optimistic locking approaches
- 14:59Database-level locking behavior
- 17:29Performance impact of database locks
- 18:54Reducing lock duration
- 20:41Optimizing transaction structure
- 21:26Version increment mechanics
- 23:37Transfer without explicit locks
- 24:19Key takeaways and best practices
- 25:05Testing concurrency approaches
- 26:33Q&A on database blocking
related talks
43mDjango Transactions: Past, Present, and Future
33mPeaceful Django Migrations with Efe Öge
25mTaking Django's ORM Async
01h 06mEffective Django
21mDjango and PostgreSQL: An Even-Closer Union
27mFinding and fixing an N+1 problem in the Django docs
57mDjangoCon 2008 Panel: Schema Evolution
23mDjango with PostgreSQL superpowers