อะไรเป็นสาเหตุของ deadlocks และคุณป้องกันได้อย่างไร?

Question

Accepted Answer

**Deadlock** เกิดขึ้นเมื่อ transaction สองตัว (หรือมากกว่า) แต่ละตัวถือ lock ที่อีกฝ่ายต้องการ ทำให้ไม่มีตัวใดดำเนินการต่อได้ — พวกมันติดอยู่ในการรอกันและกันตลอดไป ฐานข้อมูลตรวจจับ deadlocks และแก้ไขด้วยการ **ยกเลิก transaction ตัวหนึ่ง** ("เหยื่อ" หรือ victim) ซึ่งต้องลองใหม่ การเข้าใจสาเหตุและการป้องกันเป็นสิ่งสำคัญสำหรับแอปพลิเคชันแบบ concurrent

## 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
```

## ฐานข้อมูลจัดการ deadlocks อย่างไร

```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** คือ **consistent lock ordering**: หาก transaction ทั้งหมด acquire lock ในลำดับเดียวกัน (เช่น lock id ที่ต่ำกว่าก่อนเสมอ) การรอแบบวงกลม (circular wait) จะไม่สามารถก่อตัวได้

## Pattern การลองใหม่ (retry)

```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.
```

## ทำไมจึงสำคัญ

Deadlocks เป็นปัญหา concurrency ที่สำคัญในฐานข้อมูล — เกิดขึ้นในแอปพลิเคชันใด ๆ ที่มี transaction พร้อมกันซึ่งแก้ไขข้อมูลที่ทับซ้อนกัน และการเข้าใจมันเป็นความรู้ระดับ senior ที่มีคุณค่าสำหรับการสร้างระบบ concurrent ที่แข็งแกร่ง

การเข้าใจ **สาเหตุ** — transaction สองตัวแต่ละตัวถือ lock ที่อีกฝ่ายต้องการ สร้างการรอแบบวงกลมที่ไม่มีตัวใดดำเนินการต่อได้ — เป็นพื้นฐาน

การรู้ว่าฐานข้อมูล **จัดการ** deadlocks อย่างไร (ตรวจจับวงจรและยกเลิก transaction ตัวหนึ่งเป็นเหยื่อ ซึ่งต้องลองใหม่) สำคัญเพราะหมายความว่า **แอปพลิเคชันของคุณต้องจัดการข้อผิดพลาด deadlock ด้วย retry logic** — deadlocks ไม่สามารถกำจัดได้อย่างสมบูรณ์ ดังนั้นโค้ด concurrent ที่ยืดหยุ่นจึงจับข้อผิดพลาด deadlock และลองใหม่ (pattern มาตรฐานที่สำคัญ)

**กลยุทธ์การป้องกัน** เป็นความรู้ในทางปฏิบัติที่สำคัญ โดยเฉพาะเทคนิคอันดับ 1: **consistent lock ordering** (การ acquire lock ในลำดับเดียวกันเสมอข้าม transaction ทั้งหมด ซึ่งทำลายเงื่อนไข circular-wait ที่ก่อให้เกิด deadlocks) — ควบคู่ไปกับการทำให้ transaction สั้น (ถือ lock เพียงช่วงสั้น ๆ), การเข้าถึง resource ในลำดับที่สอดคล้องกัน และการหลีกเลี่ยงการดำเนินการที่ยาวนานภายใน transaction

เนื่องจาก deadlocks ก่อให้เกิดปัญหาจริง (transaction ที่ล้มเหลว, ข้อผิดพลาด, ประสิทธิภาพที่ลดลง) ในแอปพลิเคชันฐานข้อมูลแบบ concurrent และเนื่องจากการเข้าใจสาเหตุ (การรอ lock แบบวงกลม), การป้องกัน (โดยเฉพาะ consistent lock ordering และ transaction ที่สั้น) และความจำเป็นของ retry logic คือสิ่งที่ช่วยให้คุณสร้างระบบ concurrent ที่แข็งแกร่ง การเข้าใจ deadlocks จึงเป็นความรู้ระดับ senior ที่มีคุณค่าสำหรับแอปพลิเคชันใด ๆ ที่มีการเข้าถึงฐานข้อมูลพร้อมกันอย่างมีนัยสำคัญ — เป็นข้อกังวลด้านการดำเนินงานที่เกี่ยวข้องบ่อยและเป็นหัวข้อสัมภาษณ์ขั้นสูงที่พบบ่อยซึ่งแสดงถึงความเข้าใจ concurrency และความยืดหยุ่นของฐานข้อมูล