Full round replay — database deadlocks

Pass: Detects the cycle in the waits-for graph, picks a victim, and rolls that transaction back with an error — 40P01 on PostgreSQL, 1213 on MySQL. The other transaction carries on normally.

Fail: Thinks the database hangs, or that an administrator must intervene.

Pass: A Java deadlock is permanent — a thread blocked entering a monitor cannot be interrupted, so the process restarts. A database deadlock resolves in under a second, and because the rollback is atomic the victim is safe to retry. You prevent both; you retry only one.

Fail: Treats them as the same problem.

Pass: The rollback was atomic — no partial write survived and no lock is still held, so re-running is indistinguishable from having run slightly later. That is what makes a deadlock an expected retryable failure rather than an incident.

Fail: Says it just is, or worries about partial writes that cannot exist.

Pass: When the transaction had effects the rollback could not undo — an email sent, a message published, a payment call. Those need to move outside the transaction or into an outbox that publishes after commit.

Fail: Says retrying is always safe.

Pass: A consistent order on the rows every transaction touches, usually by primary key. ORDER BY id on bulk updates, or SELECT ... FOR UPDATE ... ORDER BY id to take the locks up front. A transaction not yet holding a lock cannot be in a cycle.

Fail: Says use fewer locks, or lower the isolation level.

Pass: A write statement locks the rows it examines, not just the rows it matches. Without an index the engine scans, so a statement changing one row can hold locks across the table — and two statements touching completely different rows can still form a cycle.

Fail: Has not connected indexes to locking.

Pass: Read the deadlock report — SHOW ENGINE INNODB STATUS, or the PostgreSQL log — and EXPLAIN both statements. Then three questions: do they order rows differently, does either scan rather than seek, is either transaction longer than it needs to be.

Fail: Restarts something, or raises the isolation level.

Pass: No cycle. One transaction held a lock longer than another was willing to wait. It surfaces the same way to the application and wants the opposite response — find the slow holder rather than retrying into it.

Fail: Treats them as the same, or retries both.

Pass: Two batch jobs over overlapping ids. Bulk updates take many row locks in whatever order the plan produced, so two jobs deadlock readily without anything a person would call concurrency. ORDER BY id on both, or partition the id space between them.

Fail: Assumes deadlocks require concurrent users.

Pass: Ordering cannot help with one row. Either make it a single statement so there is no window — SET count = count + 1 — or accept the serialisation and make it explicit, by sharding the counter into buckets summed on read.

Fail: Repeats the ordering answer.

Pass: Retry, but alert on the rate. Retries hide deadlocks from users, which is the point, and a climbing rate is still telling you about a real ordering problem that will get worse as traffic grows.

Fail: Retries and never measures.