Kepiye sampeyan nyegah deadlock kanthi ewonan transaksi bebarengan?

Question

IT Interview Practice · Accepted Answer

**Njupuk lock kanthi urutan global sing konsisten, jaga transaksi tetep cendhak, ngedhunake isolasi ing panggonan sing aman, lan coba maneh sing kalah nalika deadlock isih kedadeyan.** Deadlock iku siklus: transaksi A nyekel row 1 lan ngenteni row 2, dene B nyekel row 2 lan ngenteni row 1 — ora ana sing bisa maju, mula DB matèni salah siji.

## Siklus sing kudu sampeyan pecah

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

## Strategi

- **Urutan lock sing konsisten.** Yen saben transaksi tansah ngunci row kanthi urutan sing padha (contone primary key munggah), siklus ora mungkin — A lan B loro-lorone njupuk row 1 dhisik, mula siji mung ngenteni. Iki tuas paling gedhe. Bug klasik: transfer dhuwit sing ngunci akun kanthi urutan `(from, to)` deadlock karo transfer walikan; tansah ngunci miturut `min(id), max(id)`.
- **Transaksi cendhak.** Nyekel lock sacendhak-cendhake — lakonana validasi, panggilan jaringan, lan pamaca **sadurunge** `BEGIN`, banjur lock, tulis, lan `COMMIT` kanthi cepet. Transaksi dawa nambakake jendhela kanggo siklus lan tunggu lock.
- **Ngedhunake isolasi ing panggonan sing aman.** `SERIALIZABLE` njupuk luwih akeh/range lock lan luwih akeh deadlock; `READ COMMITTED` (standar Postgres) ngunci luwih sithik. Nganggo isolasi paling lemah sing isih nyukupi kebenaran.
- **Coba maneh nalika deadlock.** Deadlock iku transien. Tangkep error deadlock (Postgres `40P01`, MySQL `1213`) lan coba maneh sakabehing transaksi kanthi backoff cilik. Sawetara contention ora bisa dihindari ing skala, mula retry minangka jaring pengaman, dudu ganti kanggo urutan.

## Sudut pandang wawancara

Pewawancara mriksa apa sampeyan ngerti yen deadlock **dicegah kanthi rancangan, dudu mung ditangkep**. Nyebutake "retry" thok minangka jawaban lemah — jawaban apik banget diwiwiti karo **urutan lock konsisten** lan **transaksi cendhak**, banjur nambahake retry kanggo sisane. Jebakan umum: nganggep app kudu ndeteksi deadlock; ing praktik **DB ndeteksi siklus lan mbatalake korban** kanggo sampeyan — tugas sampeyan yaiku urutan ditambah loop retry.

**Trade-off:** urutan ketat bisa angel nalika pola akses dinamis utawa nyabrang tabel; isolasi luwih endhek ngambil risiko anomali (non-repeatable read) sing kudu sampeyan pikirake. Loop retry kudu **idempotent** lan diwatesi, yen ora konflik panas dadi badai retry. Pencegahan deadlock sejatine yaiku disiplin lock ditambah retry sing kaabatasi, dudu siji peluru perak.

Siklus sing kudu sampeyan pecah

Strategi

Sudut pandang wawancara

Pitakon sing gegandhengan