ஆயிரக்கணக்கான concurrent transactions உடன் deadlocks-ஐ எப்படித் தடுப்பீர்கள்?

Question

IT Interview Practice · Accepted Answer

**locks-ஐ ஒரு நிலையான global order-இல் acquire செய்யுங்கள், transactions-ஐ குறுகியதாக வைத்திருங்கள், பாதுகாப்பான இடத்தில் isolation-ஐக் குறைக்கவும், மேலும் ஒரு deadlock இன்னும் நடந்தால் தோற்றவரை retry செய்யுங்கள்.** ஒரு deadlock ஒரு cycle: transaction A row 1-ஐ hold செய்து row 2-க்காகக் காத்திருக்கிறது, அதே சமயம் B row 2-ஐ hold செய்து 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)
```

## Strategies

- **Consistent lock ordering.** ஒவ்வொரு transaction-ம் எப்போதும் rows-ஐ அதே order-இல் (எ.கா. ascending primary key) lock செய்தால், ஒரு cycle சாத்தியமற்றது — A மற்றும் B இருவரும் முதலில் row 1-ஐப் பிடிக்கிறார்கள், எனவே ஒருவர் வெறுமனே காத்திருக்கிறார். இது தான் ஒற்றை மிகப்பெரிய lever. ஒரு classic bug: `(from, to)` order-இல் accounts-ஐ lock செய்யும் ஒரு money transfer reverse transfer-உடன் deadlock ஆகிறது; எப்போதும் `min(id), max(id)` மூலம் lock செய்யுங்கள்.
- **Short transactions.** locks-ஐ முடிந்தவரை குறைந்த நேரம் hold செய்யுங்கள் — validation, network calls, மற்றும் reads-ஐ `BEGIN`-க்கு **முன்** செய்யுங்கள், பிறகு lock செய்து, எழுதி, வேகமாக `COMMIT` செய்யுங்கள். நீண்ட transactions cycles மற்றும் lock waits-க்கான window-ஐ விரிவுபடுத்துகின்றன.
- **பாதுகாப்பான இடத்தில் isolation-ஐக் குறைக்கவும்.** `SERIALIZABLE` அதிக/range locks எடுத்து அதிகம் deadlock ஆகிறது; `READ COMMITTED` (Postgres default) குறைவாக lock செய்கிறது. correctness-ஐ இன்னும் பூர்த்தி செய்யும் மிகப் பலவீனமான isolation-ஐப் பயன்படுத்துங்கள்.
- **deadlock-இல் Retry.** Deadlocks transient. deadlock error-ஐ (Postgres `40P01`, MySQL `1213`) catch செய்து முழு transaction-ஐயும் ஒரு சிறிய backoff உடன் retry செய்யுங்கள். அளவில் சில contention தவிர்க்க முடியாதது, எனவே retry ஒரு safety net, ordering-க்கு ஒரு பதிலீடு அல்ல.

## நேர்காணல் கண்ணோட்டம்

deadlocks **design மூலம் தடுக்கப்படுகின்றன, வெறும் catch செய்யப்படுவதில்லை** என்பதை நீங்கள் அறிவீர்களா என்று நேர்காணல் செய்பவர் சரிபார்க்கிறார். "retry"-ஐ மட்டும் குறிப்பிடுவது ஒரு பலவீனமான பதில் — சிறந்த பதில் **consistent lock ordering** மற்றும் **short transactions**-உடன் தொடங்கி, மீதத்திற்கு retry சேர்க்கிறது. ஒரு பொதுவான பொறி: app deadlocks-ஐ detect செய்ய வேண்டும் என்று கருதுவது; நடைமுறையில் **DB cycle-ஐ detect செய்து ஒரு victim-ஐ abort செய்கிறது** உங்களுக்காக — உங்கள் வேலை ordering மற்றும் ஒரு retry loop.

**சமரசங்கள்:** access patterns dynamic-ஆக இருந்தால் அல்லது tables முழுவதும் விரிந்தால் strict ordering கடினமாக இருக்கலாம்; குறைந்த isolation நீங்கள் reason செய்ய வேண்டிய anomalies (non-repeatable reads) அபாயம். Retry loops **idempotent** மற்றும் capped-ஆக இருக்க வேண்டும், இல்லையெனில் ஒரு hot conflict ஒரு retry storm ஆகிறது. Deadlock prevention உண்மையில் lock-discipline மற்றும் ஒரு bounded retry, ஒரு single silver bullet அல்ல.

நீங்கள் உடைக்க வேண்டிய cycle

Strategies

நேர்காணல் கண்ணோட்டம்

தொடர்புடைய கேள்விகள்