వేల concurrent transactions తో deadlocks ను మీరు ఎలా నివారిస్తారు?

Question

IT Interview Practice · Accepted Answer

**locks ను ఒక consistent global order లో acquire చేయండి, transactions ను చిన్నగా ఉంచండి, safe అయిన చోట isolation ను తగ్గించండి, మరియు deadlock ఇంకా జరిగినప్పుడు loser ను retry చేయండి.** ఒక deadlock ఒక cycle: transaction A row 1 ను hold చేసి row 2 కోసం వేచి ఉంటుంది, B row 2 ను hold చేసి row 1 కోసం వేచి ఉంటుంది — ఏదీ ముందుకు సాగలేదు, కాబట్టి DB ఒకదాన్ని kill చేస్తుంది.

## మీరు break చేయాల్సిన 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 లో lock చేస్తే (ఉదా. ascending primary key), ఒక cycle అసాధ్యం — A మరియు B రెండూ ముందుగా row 1 ను grab చేస్తాయి, కాబట్టి ఒకటి కేవలం వేచి ఉంటుంది. ఇది అతిపెద్ద lever. Classic bug: accounts ను `(from, to)` order లో lock చేసే ఒక money transfer reverse transfer తో deadlock అవుతుంది; ఎల్లప్పుడూ `min(id), max(id)` ద్వారా lock చేయండి.
- **Short transactions.** locks ను వీలైనంత తక్కువ సమయం hold చేయండి — validation, network calls, మరియు reads ను `BEGIN` **ముందు** చేయండి, తర్వాత lock, write, మరియు `COMMIT` వేగంగా. Long transactions cycles మరియు lock waits కోసం window ను విస్తరిస్తాయి.
- **Safe అయిన చోట Lower 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 చేయండి. scale వద్ద కొంత contention అనివార్యం, కాబట్టి retry ఒక safety net, ordering కి substitute కాదు.

## ఇంటర్వ్యూ దృక్కోణం

deadlocks **design ద్వారా నివారించబడతాయి, కేవలం catch చేయబడవు** అని మీకు తెలుసా అని ఇంటర్వ్యూయర్ check చేస్తారు. కేవలం "retry" ను పేర్కొనడం ఒక బలహీన సమాధానం — గొప్ప సమాధానం **consistent lock ordering** మరియు **short transactions** తో మొదలై, తర్వాత residual కోసం retry ను జోడిస్తుంది. ఒక సాధారణ ఉచ్చు: app deadlocks ను detect చేయాలని భావించడం; ఆచరణలో **DB cycle ను detect చేసి ఒక victim ను abort చేస్తుంది** మీ కోసం — మీ పని ordering ప్లస్ ఒక retry loop.

**Trade-offs:** access patterns dynamic గా ఉన్నప్పుడు లేదా tables ను span చేసినప్పుడు strict ordering కష్టం కావచ్చు; lower isolation మీరు reason చేయాల్సిన anomalies (non-repeatable reads) risk. Retry loops **idempotent** మరియు capped గా ఉండాలి, లేదా ఒక hot conflict ఒక retry storm గా మారుతుంది. Deadlock prevention నిజంగా lock-discipline ప్లస్ ఒక bounded retry, ఒక single silver bullet కాదు.

మీరు break చేయాల్సిన cycle

Strategies

ఇంటర్వ్యూ దృక్కోణం

సంబంధిత ప్రశ్నలు