# Transaction Lock And Retry

## Question

At which pessimistic/optimistic transaction phase does the request wait or
retry, and which lock, conflict, deadlock, or retry layer causes it?

## Enter When

Use for `Locked`, `WriteConflict`, deadlock, lock-wait timeout,
PessimisticLockNotFound, retry storms, or questions about transaction flow.

## First Batch

1. Classify transaction mode and the failing phase: begin/StartTS, prewrite,
   acquire pessimistic lock, commit, resolve lock, or client retry.
2. Align the exact error/backoff/lock wait with the affected digest,
   transaction, key/region, and TiKV/TiDB instance where available.
3. Check the strongest alternative phase or server/client counterpart.

## Decision

Do not merge distinct retry layers. A client retry can hide a server conflict;
a stale lock can be a consequence rather than the original trigger. Treat
version-dependent transaction semantics, fair-locking behavior, and known bug
matches as hypotheses until current documentation and direct evidence agree.

## Strongest Alternative And Stop

Stop after one phase and mechanism are bounded plus one adjacent phase is
checked. For correctness/data-loss suspicion, preserve evidence and require
human review; do not recommend unsafe cleanup or mutation.