Group
  • Database

    Diagnose and fix database lock contention

    Finds long-running transactions and lock-heavy code paths, then shortens transactions and adds deadlock retry handling.

    • Debug & fix
    • Improve quality
    • Advanced
    • General

Free Prompt

My database sometimes hangs under load: requests pile up, some queries sit waiting, and I occasionally see deadlock or lock-wait-timeout errors. Diagnose the lock contention in my app and fix it. 1. Find the offenders: identify transactions that stay open too long. Look for transactions that make external API calls, send emails, do file I/O, or run slow queries while holding a transaction open, and transactions that touch many rows at once (bulk updates inside a transaction). 2. Shorten them: restructure so external calls happen outside the transaction. Keep transactions to the smallest set of statements that must be atomic. 3. Order consistently: where multiple rows or tables get updated in one transaction, make every code path lock them in the same order (for example, always update the parent row before child rows) to break deadlock cycles. 4. Retry deadlocks: add a retry wrapper for deadlock/serialization errors, with a short backoff and a small attempt cap. Deadlocks under concurrency are normal; the app should absorb them, not 500. 5. Add guardrails: set a statement timeout and idle-in-transaction timeout so a stuck transaction cannot hold locks forever. Do not weaken isolation levels to make the errors disappear without explaining the consistency tradeoff first. Do not remove transactions that exist for correctness; shrink them. Give me a list of the transactions you found, what moved out of each one, the retry logic added, and the timeout values you set.

What This Does / How This Helps

Hunts down the transactions that hold locks too long, shrinks them, and makes deadlocks survivable with retries. Lock contention has a recognizable signature: everything is fine at low traffic, then under load requests start queueing behind one stuck transaction and the whole app grinds. The usual cause in vibe-coded apps is a transaction that wraps way more than it needs to, like a checkout flow that calls Stripe while holding row locks. The prompt restructures the worst offenders, enforces consistent lock ordering to prevent deadlock cycles, and adds retry handling so the deadlocks that still happen get absorbed instead of surfaced to users.

Want to skip doing this by hand?

Fortivibe audits your app for all of the areas these prompts cover (and more).

See What We Check

Related Prompts