Si i parandaloni deadlocks me mijëra transaksione konkurrente?

Question

IT Interview Practice · Accepted Answer

**Merrni locks në një renditje globale konsistente, mbani transaksionet të shkurtra, ulni isolation ku është e sigurt, dhe riprovoni humbësin kur një deadlock ende ndodh.** Një deadlock është një cikël: transaksioni A mban row 1 dhe pret për row 2, ndërsa B mban row 2 dhe pret për row 1 — asnjëri nuk mund të vazhdojë, kështu që DB vret njërin.

## Cikli që duhet të thyeni

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

## Strategjitë

- **Renditje konsistente lock-ash.** Nëse çdo transaksion gjithmonë bllokon rreshtat në të njëjtën renditje (p.sh. primary key ngjitës), një cikël është i pamundur — A dhe B të dy kapin row 1 së pari, kështu që njëri thjesht pret. Kjo është leva e vetme më e madhe. Një bug klasik: një transfertë parash që bllokon llogaritë në renditjen `(from, to)` bën deadlock me transfertën e kundërt; gjithmonë bllokoni sipas `min(id), max(id)`.
- **Transaksione të shkurtra.** Mbani locks për sa më pak kohë të jetë e mundur — bëni validim, thirrje rrjeti, dhe lexime **para** `BEGIN`, pastaj bllokoni, shkruani, dhe `COMMIT` shpejt. Transaksionet e gjata zgjerojnë dritaren për cikle dhe lock waits.
- **Ulni isolation ku është e sigurt.** `SERIALIZABLE` merr më shumë/range locks dhe bën më shumë deadlock; `READ COMMITTED` (default i Postgres) bllokon më pak. Përdorni isolation-in më të dobët që ende plotëson korrektësinë.
- **Riprovoni në deadlock.** Deadlocks janë kalimtare. Kapni gabimin e deadlock (Postgres `40P01`, MySQL `1213`) dhe riprovoni të gjithë transaksionin me backoff të vogël. Pak contention është e pashmangshme në shkallë, kështu që retry është një rrjetë sigurie, jo një zëvendësim për renditjen.

## Këndvështrimi i intervistës

Intervistuesi kontrollon nëse dini se deadlocks **parandalohen me dizajn, jo thjesht kapen**. Emërtimi i "retry" vetëm është një përgjigje e dobët — përgjigja e shkëlqyer udhëheq me **renditje konsistente lock-ash** dhe **transaksione të shkurtra**, pastaj shton retry për të mbeturën. Një kurth i zakonshëm: supozimi se aplikacioni duhet të zbulojë deadlocks; në praktikë **DB zbulon ciklin dhe abort-on një viktimë** për ju — puna juaj është renditja plus një retry loop.

**Kompromiset:** renditja strikte mund të jetë e vështirë kur access patterns janë dinamike ose mbulojnë tabela; isolation më i ulët rrezikon anomali (non-repeatable reads) që duhet t'i arsyetoni. Retry loops duhet të jenë **idempotentë** dhe të kufizuar, ose një konflikt i nxehtë kthehet në një retry storm. Parandalimi i deadlock është vërtet disiplinë lock-ash plus një retry të kufizuar, jo një zgjidhje e vetme magjike.

Cikli që duhet të thyeni

Strategjitë

Këndvështrimi i intervistës

Pyetje të ngjashme