The Very Hungry Transaction
summary
A single database transaction grows into a liability: inserts plus hundreds or thousands of updates cause deadlock errors and lock timeouts, slow queries and transactions over several seconds create contention, and an external HTTP call inside a transaction ties up DB connections until the external service times out causing sitewide failures. Background jobs enqueued before commit generate retries and queue backups; switching to after_create_commit enqueues only on success, add indexes to speed updates, and limit batch sizes to avoid thousands of queries.
AI-written summary · about
chapters (28)
- 0:00Introduction
- 1:06Cat and hungry transaction story
- 3:16Monday’s simple transaction
- 5:02Tuesday’s inventory update and locks
- 9:19Slow transactions invite contention
- 10:00Speeding up update queries
- 12:29Questioning transaction need
- 12:50Moving work out of request
- 13:33Jobs before commit can fail
- 15:01Queued retries blocking jobs
- 16:27Wednesday’s job improvements
- 16:49Thursday’s external call
- 18:14External calls threaten database
- 20:21Moving calls outside transactions
- 21:44Friday’s database overload
- 22:47Nested transactions risks
- 24:11Non-atomic inventory updates
- 25:14Making operations explicit
- 26:39Weekend reflections on risks
- 27:43Slow transactions affect app
- 28:46Monday’s monster transaction
- 29:28Rewriting transactions
- 30:32Rails 7.2 deferring work
- 30:54Tools for transactions
- 31:36Preventing bad transactions
- 32:20Writing safe transactions
- 33:44GitHub’s real problems
- 34:05Q&A
related talks
32mThe Very Hungry Transaction
33mThe Very Hungry Transaction
42mA Race To The Bottom: Database Transactions Undermining Your AppSec
41mConcurrency, Scalability and Transactions -- Myths and Surprises
20mCRUD! The Consequences of Not Understanding How ActiveRecord ...
50mSupercharge your Code to Get Optimal Database Performance
40mrails db:migrate:safely
29mThings might go wrong in a data-intensive application