ਤੁਸੀਂ ਹਜ਼ਾਰਾਂ concurrent transactions ਨਾਲ deadlocks ਨੂੰ ਕਿਵੇਂ ਰੋਕਦੇ ਹੋ?

Question

IT Interview Practice · Accepted Answer

**locks ਨੂੰ ਇੱਕ consistent global order ਵਿੱਚ acquire ਕਰੋ, transactions ਨੂੰ ਛੋਟਾ ਰੱਖੋ, ਜਿੱਥੇ ਸੁਰੱਖਿਅਤ ਹੋਵੇ ਓਥੇ isolation ਘਟਾਓ, ਅਤੇ ਜਦੋਂ deadlock ਫਿਰ ਵੀ ਹੋ ਜਾਵੇ ਤਾਂ loser ਨੂੰ retry ਕਰੋ।** ਇੱਕ deadlock ਇੱਕ cycle ਹੈ: transaction A row 1 ਰੱਖਦਾ ਹੈ ਅਤੇ row 2 ਲਈ ਇੰਤਜ਼ਾਰ ਕਰਦਾ ਹੈ, ਜਦਕਿ B row 2 ਰੱਖਦਾ ਹੈ ਅਤੇ row 1 ਲਈ ਇੰਤਜ਼ਾਰ ਕਰਦਾ ਹੈ — ਕੋਈ ਵੀ ਅੱਗੇ ਨਹੀਂ ਵਧ ਸਕਦਾ, ਇਸ ਲਈ DB ਇੱਕ ਨੂੰ ਮਾਰ ਦਿੰਦਾ ਹੈ।

## ਓਹ cycle ਜਿਸਨੂੰ ਤੁਹਾਨੂੰ ਤੋੜਨਾ ਪਵੇਗਾ

```text
   Tx A                              Tx B
   holds row 1  ──── waits ────▶ row 2 (held by B)
        ▲                              │
        │ waits                        │ holds
        └────────── row 1 ◀────────────┘
                (cycle = deadlock; DB aborts one victim)
```

## ਰਣਨੀਤੀਆਂ

- **Consistent lock ordering.** ਜੇ ਹਰ transaction ਹਮੇਸ਼ਾ rows ਨੂੰ ਓਹੀ order ਵਿੱਚ lock ਕਰੇ (ਜਿਵੇਂ ascending primary key), ਤਾਂ ਇੱਕ cycle ਅਸੰਭਵ ਹੈ — A ਅਤੇ B ਦੋਵੇਂ row 1 ਪਹਿਲਾਂ ਫੜਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਬਸ ਇੰਤਜ਼ਾਰ ਕਰਦਾ ਹੈ। ਇਹ ਸਭ ਤੋਂ ਵੱਡਾ lever ਹੈ। ਇੱਕ classic bug: ਇੱਕ money transfer ਜੋ accounts ਨੂੰ `(from, to)` order ਵਿੱਚ lock ਕਰਦਾ ਹੈ ਉਹ reverse transfer ਨਾਲ deadlock ਕਰਦਾ ਹੈ; ਹਮੇਸ਼ਾ `min(id), max(id)` ਨਾਲ lock ਕਰੋ।
- **Short transactions.** locks ਨੂੰ ਜਿੰਨਾ ਘੱਟ ਹੋ ਸਕੇ ਓਨਾ ਸਮਾਂ ਰੱਖੋ — validation, network calls, ਅਤੇ reads `BEGIN` ਤੋਂ **ਪਹਿਲਾਂ** ਕਰੋ, ਫਿਰ lock ਕਰੋ, write ਕਰੋ, ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ `COMMIT` ਕਰੋ। ਲੰਬੇ transactions cycles ਅਤੇ lock waits ਲਈ window ਚੌੜੀ ਕਰਦੇ ਹਨ।
- **ਜਿੱਥੇ ਸੁਰੱਖਿਅਤ ਹੋਵੇ isolation ਘਟਾਓ.** `SERIALIZABLE` ਵੱਧ/range locks ਲੈਂਦਾ ਹੈ ਅਤੇ ਵੱਧ deadlock ਕਰਦਾ ਹੈ; `READ COMMITTED` (Postgres default) ਘੱਟ lock ਕਰਦਾ ਹੈ। ਓਹ ਸਭ ਤੋਂ ਕਮਜ਼ੋਰ isolation ਵਰਤੋ ਜੋ ਅਜੇ ਵੀ correctness ਪੂਰੀ ਕਰੇ।
- **Deadlock ਉੱਤੇ retry.** Deadlocks transient ਹਨ। deadlock error (Postgres `40P01`, MySQL `1213`) ਫੜੋ ਅਤੇ ਪੂਰੇ transaction ਨੂੰ ਇੱਕ ਛੋਟੇ backoff ਨਾਲ retry ਕਰੋ। scale ਉੱਤੇ ਕੁਝ contention ਅਟੱਲ ਹੈ, ਇਸ ਲਈ retry ਇੱਕ safety net ਹੈ, ordering ਦਾ ਬਦਲ ਨਹੀਂ।

## ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਇੰਟਰਵਿਊਅਰ ਚੈੱਕ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ deadlocks **design ਦੁਆਰਾ ਰੋਕੇ ਜਾਂਦੇ ਹਨ, ਸਿਰਫ਼ ਫੜੇ ਨਹੀਂ ਜਾਂਦੇ**। ਇਕੱਲੇ "retry" ਦਾ ਨਾਂ ਲੈਣਾ ਇੱਕ ਕਮਜ਼ੋਰ ਜਵਾਬ ਹੈ — ਸ਼ਾਨਦਾਰ ਜਵਾਬ **consistent lock ordering** ਅਤੇ **short transactions** ਨਾਲ ਅਗਵਾਈ ਕਰਦਾ ਹੈ, ਫਿਰ ਬਚੇ-ਖੁਚੇ ਲਈ retry ਜੋੜਦਾ ਹੈ। ਇੱਕ ਆਮ ਫੰਦਾ: ਇਹ ਮੰਨਣਾ ਕਿ app ਨੂੰ deadlocks detect ਕਰਨੇ ਪੈਣਗੇ; ਅਸਲ ਵਿੱਚ **DB cycle detect ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਲਈ ਇੱਕ victim abort ਕਰ ਦਿੰਦਾ ਹੈ** — ਤੁਹਾਡਾ ਕੰਮ ordering ਨਾਲ ਇੱਕ retry loop ਹੈ।

**Trade-offs:** ਸਖ਼ਤ ordering ਓਦੋਂ ਔਖੀ ਹੋ ਸਕਦੀ ਹੈ ਜਦੋਂ access patterns dynamic ਹੋਣ ਜਾਂ tables ਦੇ ਪਾਰ ਫੈਲਣ; ਘੱਟ isolation anomalies (non-repeatable reads) ਦਾ ਖਤਰਾ ਹੈ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਤੁਹਾਨੂੰ ਸੋਚਣਾ ਪਵੇਗਾ। Retry loops **idempotent** ਅਤੇ capped ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਨਹੀਂ ਤਾਂ ਇੱਕ hot conflict ਇੱਕ retry storm ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ। Deadlock prevention ਅਸਲ ਵਿੱਚ lock-discipline ਨਾਲ ਇੱਕ bounded retry ਹੈ, ਇੱਕ single silver bullet ਨਹੀਂ।

ਓਹ cycle ਜਿਸਨੂੰ ਤੁਹਾਨੂੰ ਤੋੜਨਾ ਪਵੇਗਾ

ਰਣਨੀਤੀਆਂ

ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਸੰਬੰਧਿਤ ਸਵਾਲ