რა იწვევს deadlock-ებს და როგორ აღიკვეთებთ მათ?

Question

Accepted Answer

**Deadlock** ხდება მაშინ, როდესაც ორი (ან მეტი) ტრანზაქცია ერთმანეთის მიერ საჭირო lock-ს ხელში უჭირავს, ამიტომ არცერთი ვერ გრძელდება — ისინი უსასრულოდ ერთმანეთის জადოსზე ელოდებიან. მონაცემთა ბაზები deadlock-ებს აღმოაჩენენ და მათ გადაჭრიან **ერთი ტრანზაქციის შეწყვეტით** ("victim"-ი), რომელმაც ხელახლა უნდა სცადოს. მიზეზების და პრევენციის გაგება중요 არის კონკურენტული აპლიკაციებისთვის.

## როგორ ხდება deadlock

```text
Transaction A: locks row 1, then wants row 2
Transaction B: locks row 2, then wants row 1
→ A waits for B (to release row 2), B waits for A (to release row 1) → DEADLOCK
  Neither can proceed; they're waiting on each other in a cycle.
```

```sql
-- Transaction A                    -- Transaction B (concurrent)
BEGIN;                              BEGIN;
UPDATE accounts SET .. WHERE id=1;  UPDATE accounts SET .. WHERE id=2;  -- each locks a row
UPDATE accounts SET .. WHERE id=2;  UPDATE accounts SET .. WHERE id=1;  -- each wants the OTHER's
-- → DEADLOCK: the database aborts one transaction
```

## როგორ მუშაობენ მონაცემთა ბაზები deadlock-ებთან

```text
Databases DETECT deadlocks (find the cycle of waiting transactions) and resolve them
by ABORTING one transaction (the victim) with a deadlock error → it must RETRY.
→ Your application must handle the deadlock error and retry the transaction.
```

## პრევენციის სტრატეგიები

```text
✓ CONSISTENT LOCK ORDERING — always acquire locks in the SAME order (e.g. always
  lock the lower account id first). This breaks the cycle → the #1 prevention technique.
✓ Keep transactions SHORT — hold locks for less time (less chance to overlap)
✓ Access tables/rows in a consistent order across all transactions
✓ Use lower isolation levels where appropriate (less locking)
✓ Avoid user interaction / long operations inside a transaction (holds locks too long)
✓ Handle deadlock errors with RETRY logic (deadlocks can't be fully eliminated)
```

**#1 პრევენცია** არის **თანმიმდევრული lock ordering**: თუ ყველა ტრანზაქცია lock-ებს ერთი და იმავე თანმიმდევრობით იღებს (მაგ. ყოველთვის დაბალი id პირველი), წრიული ლოდინი არ შეიძლება წარმოიშვას.

## retry pattern-ი

```text
Since deadlocks can still happen, applications should catch the deadlock error and
RETRY the transaction (often a few times with a small delay). This is standard
resilience for concurrent database code.
```

## რატომ აქვს ამას მნიშვნელობა

Deadlock-ები მნიშვნელოვანი concurrency საკითხია მონაცემთა ბაზებში — ისინი წარმოიქმნება ნებისმიერ აპლიკაციაში კონკურენტული ტრანზაქციებით, რომლებიც გადახურული მონაცემებს ცვლის, და მათი გაგება ღირებული senior-level ცოდნაა მყარი კონკურენტული სისტემების აგებისთვის.

**მიზეზის** გაგება — ორი ტრანზაქცია ერთმანეთის მიერ საჭირო lock-ს ხელში უჭირავს, რაც ქმნის წრიულ ლოდინს, სადაც არცერთი ვერ გრძელდება — არის საფუძველი.

თუ იცით, რომ მონაცემთა ბაზები **მუშაობენ** deadlock-ებთან (აღმოაჩენენ ციკლს და აჩერებენ ერთი ტრანზაქციას victim-ად, რომელმაც ხელახლა უნდა სცადოს), ეს მნიშვნელოვანია, რადგან ეს ნიშნავს, რომ თქვენი **აპლიკაცია უნდა მოემგავოს deadlock ошибк-ებს retry ლოგიკით** — deadlock-ების სრულად აღკვეთა შეუძლებელია, ამიტომ resilient კონკურენტული კოდი ловит deadlock ошибку და ხელახლა სცადის (სტანდარტული, მნიშვნელოვანი pattern).

**პრევენციის სტრატეგიები** არის მთავარი პრაქტიკული ცოდნა, განსაკუთრებით #1 ტექნიკა: **თანმიმდევრული lock ordering** (ყოველთვის lock-ების აღება ერთი და იმავე თანმიმდევრობით ყველა ტრანზაქციაში, რაც ღებულობს წრიული-ლოდინის პირობას, რომელიც იწვევს deadlock-ებს) — ასევე ტრანზაქციების მოკლე დებულება (lock-ების მოკლე დროის საშუალებით), რესურსების თანმიმდევრული დოქას თანმიმდევრობით და გრძელი ოპერაციების თავიდან აცილება ტრანზაქციებში.

ვინაიდან deadlock-ები რეალური პრობლემებს იწვევს (ტრანზაქციების წარუმატებელი დასრულება, ошибки, დეგრადირებული მუშაობა) კონკურენტული მონაცემთა ბაზის აპლიკაციებში, და მათი მიზეზის გაგება (წრიული lock ლოდინი), პრევენცია (განსაკუთრებით თანმიმდევრული lock ordering და მოკლე ტრანზაქციები), და retry ლოგიკის აუცილებელობა არის ის, რაც საშუალებას გაძლევთ ააგოთ მყარი კონკურენტული სისტემები, deadlock-ების გაგება ღირებული senior-level ცოდნაა ნებისმიერი აპლიკაციისთვის მნიშვნელოვანი კონკურენტული მონაცემთა ბაზის წვდომით — ხშირად შესაბამისი ოპერაციული ღრმეტი და საერთო advanced ინტერვიუს თემა, რომელიც აჩვენებს მონაცემთა ბაზის კონკურენტობის და resilience-ის გაგებას.