ਡੈੱਡਲਾਕ ਕਿਸ ਕਾਰਨ ਹੁੰਦੇ ਹਨ ਅਤੇ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਰੋਕਦੇ ਹੋ?

Question

Accepted Answer

ਇੱਕ **deadlock** ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਦੋ (ਜਾਂ ਵੱਧ) transactions ਇੱਕ ਲਾਕ ਰੱਖਦੇ ਹਨ ਜੋ ਦੂਸਰੇ ਨੂੰ ਚਾਹੀਦਾ ਹੈ, ਇਸ ਲਈ ਕੋਈ ਵੀ ਅੱਗੇ ਨਹੀਂ ਬੜ੍ਹ ਸਕਦਾ — ਉਹ ਇੱਕ ਦੂਸਰੇ ਦਾ ਹਮੇਸ਼ਾ ਸਾਹ ਲੁਕਾ ਕੇ ਫਸ ਜਾਂਦੇ ਹਨ। Databases deadlocks ਨੂੰ ਖੋਜਦੇ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ **ਇੱਕ transaction ਨੂੰ abort ਕਰਕੇ** ਹੱਲ ਕਰਦੇ ਹਨ ("victim"), ਜੋ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ। Concurrent applications ਲਈ ਕਾਰਨ ਅਤੇ ਬਚਾਅ ਨੂੰ ਸਮਝਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ।

## ਡੈੱਡਲਾਕ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ

```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
```

## Databases 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.
```

## ਬਚਾਅ ਦੀ ਰਣਨੀਤਿ

```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 ਬਚਾਅ** ਹੈ **consistent lock ordering**: ਜੇਕਰ ਸਾਰੇ transactions locks ਨੂੰ ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਲੈਂਦੇ ਹਨ (ਉਦਾਹਰਨ ਲਈ ਹਮੇਸ਼ਾ ਘੱਟ id ਪਹਿਲੇ), ਤਾਂ ਚੱਕਰੀ ਕਾਂ ਨਹੀਂ ਬਣ ਸਕਦਾ।

## Retry pattern

```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.
```

## ਇਹ ਮਹੱਤਵ ਕਿਉਂ ਰੱਖਦਾ ਹੈ

Deadlocks databases ਵਿੱਚ ਇੱਕ ਮਹੱਤਵਪੂਰਨ concurrency ਸਮੱਸਿਆ ਹਨ — ਇਹ ਕਿਸੇ ਵੀ application ਵਿੱਚ ਹੁੰਦੇ ਹਨ ਜਿਸ ਵਿੱਚ concurrent transactions ਹਨ ਜੋ overlapping data ਨੂੰ modify ਕਰਦੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਸਮਝਣਾ robust concurrent systems ਬਣਾਉਣ ਲਈ senior-level ਦਾ ਮੂਲਯਵਾਨ ਗਿਆਨ ਹੈ।

**ਕਾਰਨ** ਨੂੰ ਸਮਝਣਾ — ਦੋ transactions ਇੱਕ ਲਾਕ ਰੱਖਦੇ ਹਨ ਜੋ ਦੂਸਰੇ ਨੂੰ ਚਾਹੀਦਾ ਹੈ, ਇੱਕ circular wait ਬਣਾਉਂਦੇ ਹਾਂ ਜਿੱਥੇ ਕੋਈ ਵੀ ਅੱਗੇ ਨਹੀਂ ਬੜ੍ਹ ਸਕਦਾ — ਇਹ ਬੁਨਿਆਦ ਹੈ।

jankari ਕਿ databases **deadlocks ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦੇ ਹਨ** (cycle ਨੂੰ detect ਕਰਕੇ ਅਤੇ ਇੱਕ transaction ਨੂੰ victim ਬਣਾ ਕੇ abort ਕਰਨਾ, ਜੋ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ) ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡੀ **application ਨੂੰ deadlock errors ਨੂੰ retry logic ਦੇ ਨਾਲ ਸੰਭਾਲਣਾ ਲਾਜ਼ਮੀ ਹੈ** — deadlocks ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਤਮ ਨਹੀਂ ਕੀਤੇ ਜਾ ਸਕਦੇ, ਇਸ ਲਈ resilient concurrent code deadlock error ਨੂੰ catch ਕਰਦਾ ਹੈ ਅਤੇ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ (ਇੱਕ standard, ਮਹੱਤਵਪੂਰਨ pattern)।

**ਬਚਾਅ ਦੀ ਰਣਨੀਤਿ** ਮੁੱਖ ਵਿਆਵਹਾਰਿਕ ਗਿਆਨ ਹਨ, ਖਾਸ ਤੌਰ 'ਤੇ #1 ਤਕਨੀਕ: **consistent lock ordering** (ਹਮੇਸ਼ਾ ਸਾਰੇ transactions ਵਿੱਚ ਲਾਕ ਨੂੰ ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ acquire ਕਰਨਾ, ਜੋ circular-wait condition ਨੂੰ ਭੰਗ ਕਰਦਾ ਹੈ ਜੋ deadlocks ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ) — ਨਾਲ ਹੀ transactions ਨੂੰ ਛੋਟਾ ਰੱਖਣਾ (locks ਨੂੰ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਰੱਖਣਾ), resources ਨਾ access ਕਰਨਾ ਇੱਕ consistent order ਵਿੱਚ, ਅਤੇ transactions ਦੇ ਅੰਦਰ ਲੰਬੀਆਂ operations ਤੋਂ ਬਚਨਾ।

Chiksa ਤਕ deadlocks ਅਸਲ ਸਮੱਸਿਆਵਾਂ ਦਾ ਕਾਰਨ ਬਣਦੇ ਹਨ (failed transactions, errors, degraded performance) concurrent database applications ਵਿੱਚ, ਅਤੇ ਚਿੱਤਰ ਤਕ ਉਨ੍ਹਾਂ ਦਾ ਕਾਰਨ (circular lock waits), ਬਚਾਅ (ਖਾਸ ਤੌਰ 'ਤੇ consistent lock ordering ਅਤੇ short transactions), ਅਤੇ retry logic ਦੀ ਜ਼ਰੂਰਤ ਨੂੰ ਸਮਝਣਾ ਹੈ ਜੋ ਤੁਹਨੂੰ robust concurrent systems ਬਣਾਉਣ ਦਿੰਦਾ ਹੈ, deadlocks ਨੂੰ ਸਮਝਣਾ ਕਿਸੇ ਵੀ application ਨਾਲ significant concurrent database access ਲਈ senior-level ਦਾ ਮੂਲਯਵਾਨ ਗਿਆਨ ਹੈ — ਇੱਕ frequently-relevant operational ਚਿੰਤਾ ਅਤੇ ਇੱਕ common advanced interview ਵਿਸ਼ਾ ਜੋ database concurrency ਅਤੇ resilience ਦੀ ਸਮਝ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦਾ ਹੈ।