Me ke haifar da deadlocks kuma me ne za ka yi don kawar da su?

Question

Accepted Answer

A **deadlock** ya faru lokacin da juna (ko fiye) transactions kowannen yana riƙe da lock wanda juna ne suke buƙata, don haka babu wanda zai iya ci gaba — sun takura suna jira juna har abada. Databases suna gano deadlocks kuma suna warware su ta hanyar **kawar da wata transaction** ("victim"), wacce dole ne ta sake gudun aiki. Fahimtar dalilan da hanyoyin kawar da su yana da mahimmanci ga aikace-aikacen da ke aiki daidai.

## Yadda deadlock ya faru

```text
Transaction A: locks row 1, then wants row 2
Transaction B: locks row 2, then wants row 1
→ A waits for B (to release row 2), B waits for A (to release row 1) → DEADLOCK
  Neither can proceed; they're waiting on each other in a cycle.
```

```sql
-- Transaction A                    -- Transaction B (concurrent)
BEGIN;                              BEGIN;
UPDATE accounts SET .. WHERE id=1;  UPDATE accounts SET .. WHERE id=2;  -- each locks a row
UPDATE accounts SET .. WHERE id=2;  UPDATE accounts SET .. WHERE id=1;  -- each wants the OTHER's
-- → DEADLOCK: the database aborts one transaction
```

## Yadda databases suke jaki deadlocks

```text
Databases DETECT deadlocks (find the cycle of waiting transactions) and resolve them
by ABORTING one transaction (the victim) with a deadlock error → it must RETRY.
→ Your application must handle the deadlock error and retry the transaction.
```

## Hanyoyin kawar da su

```text
✓ CONSISTENT LOCK ORDERING — always acquire locks in the SAME order (e.g. always
  lock the lower account id first). This breaks the cycle → the #1 prevention technique.
✓ Keep transactions SHORT — hold locks for less time (less chance to overlap)
✓ Access tables/rows in a consistent order across all transactions
✓ Use lower isolation levels where appropriate (less locking)
✓ Avoid user interaction / long operations inside a transaction (holds locks too long)
✓ Handle deadlock errors with RETRY logic (deadlocks can't be fully eliminated)
```

**#1 hanyar kawar** ita ce **consistent lock ordering**: idan duk transactions suna tsamanin locks a jiya daya (m.s. koyaushe karamin id na farko), circular wait ba zai iya samuwa.

## Yiwuwar sake koyi

```text
Since deadlocks can still happen, applications should catch the deadlock error and
RETRY the transaction (often a few times with a small delay). This is standard
resilience for concurrent database code.
```

## Me yasa ya ce mahimmanci

Deadlocks aikin muhimmancin concurrency ne a databases — suna faru a kowane aikacen da ke da transactions da ke aiki daidai wanda ke canja overlapping data, kuma fahimtar su yana da ƙima ga ilmin senior-level don gina abubuwan da ke aiki daidai masu ƙarfi.

Fahimtar **dalili** — transactions biyu kowannen yana riƙe da lock wanda juna ne suke buƙata, suna haifar da circular wait inda babu wanda zai iya ci gaba — shine tushe.

Sanin yadda databases **jaki** deadlocks (gano recursive kuma kawar da wata transaction azaman victim, wacce dole ne ta sake gudun aiki) yana da muhimmanci saboda kusan nufin **aikacen ka dole ne ya jaki deadlock errors tare da retry logic** — ba za a iya kawar da deadlocks gaba daya, don haka robust concurrent code na kama deadlock error kuma ya sake koyi (misali na yiwuwar, mahimmanci).

**Hanyoyin kawar** su ne mahimmancin ilmin aiki, musamman **#1 fasaha: **consistent lock ordering** (koyaushe samu locks a jiya daya a cikin duk transactions, wanda ya karya circular-wait yanayin da ya haifar da deadlocks) — tare da riƙon transactions na gida (riƙe da locks a takaice), samun resources a jiya daya, kuma guje wa ayyukan dogon lokaci a cikin transactions.

Saboda deadlocks suna haifar da abubuwa masu laifi (kaciyar transactions, kurakurai, raunin aiki) a aikacen database da ke aiki daidai, kuma saboda fahimtar dalili-su (circular lock waits), kawar (musamman consistent lock ordering da short transactions), kuma bukatun retry logic shine wanda ya ƙi ka gina abubuwan da ke aiki daidai masu ƙarfi, fahimtar deadlocks yana da ƙima ga ilmin senior-level ga kowane aikacen tare da babbar daidaita database access — mahimmancin aikin aiki koyaushe kuma babbacin jira ta interview tare da fahimta na database concurrency da resilience.