Transactions & Concurrency Control

1Transaction และคุณสมบัติ ACID

บทนี้เน้นที่ Isolation เป็นหลัก เพราะเป็นคุณสมบัติที่ซับซ้อนที่สุดในการรับประกันเมื่อมี concurrency

2ปัญหาที่เกิดขึ้นเมื่อไม่มี Concurrency Control

3Locking: กลไก Pessimistic Concurrency Control

Two-Phase Locking (2PL)

Deadlock: การติดตายเมื่อรอ Lock กันเป็นวงกลม

4Optimistic Concurrency Control (OCC)

5Timestamp Ordering

6ทันสมัย: MVCC และ Isolation Level ในฐานข้อมูลปัจจุบัน

7Transaction รักษา Invariant ไม่ใช่เพียงรวมคำสั่งหลายบรรทัด

คนมักอธิบาย transaction ว่า “ทำทั้งหมดหรือไม่ทำเลย” ซึ่งครอบ Atomicity แต่ยังไม่อธิบายว่าทำไปเพื่ออะไร แก่นจริงคือการรักษา invariant หรือเงื่อนไขที่ต้องเป็นจริงของข้อมูล เช่นยอดเงินรวมไม่หาย ที่นั่งหนึ่งที่ไม่ขายให้สองคน และ stock ไม่ติดลบโดยไม่มีนโยบายรองรับ

Consistency ใน ACID ไม่ได้หมายถึง replica ทุกชุดเห็นข้อมูลเหมือนกันแบบ distributed consistency แต่หมายถึง transaction ที่ถูกต้องพาระบบจาก state ที่ invariant เป็นจริงไปยังอีก state ที่ invariant ยังเป็นจริง ฐานข้อมูลช่วยด้วย constraint และ isolation แต่ business invariant ที่ไม่ประกาศให้ระบบรู้ยังเป็นหน้าที่ของ application

Application check ที่ดูถูกแต่แข่งกันได้

if stock >= quantity:
    stock = stock - quantity
    save(stock)

โค้ดนี้ถูกในโลกทีละ request แต่ผิดเมื่อสอง transaction อ่าน stock เดิมพร้อมกัน การตรวจแล้วเขียนเป็นสองเหตุการณ์ ถ้าไม่มี lock, version check หรือ atomic SQL update ทั้งคู่ผ่านเงื่อนไขได้ การเขียนโค้ดที่ “อ่านง่าย” ไม่ได้ทำให้ schedule ถูกต้อง

8จาก Interleaving ไปสู่ Serializability

Concurrency ทำให้ operation ของหลาย transaction สลับกันได้ เราไม่จำเป็นต้องบังคับให้รันทีละ transaction เพราะจะเสีย parallelism เป้าหมายคืออนุญาต interleaving ที่ผลเทียบเท่ากับ serial order บางลำดับ สิ่งนี้เรียกว่า serializability

Operation conflict เมื่อมาจากคนละ transaction เข้าถึง item เดียวกัน และอย่างน้อยหนึ่ง operation เป็น write: read–write, write–read และ write–write ส่วน read–read สลับกันได้โดยไม่เปลี่ยนผล

T1: R(A) W(A)       T2: R(A) W(A)

Schedule S: R1(A), R2(A), W1(A), W2(A)

ถ้าทั้งคู่เพิ่มค่า A จาก 10 คนละ 5 ต่างอ่าน 10 และเขียน 15 ผลสุดท้ายเป็น 15 แทน 20 นี่คือ lost update Schedule ไม่เทียบเท่ากับการรัน T1→T2 หรือ T2→T1 ซึ่งควรได้ 20

Precedence/Serialization Graph

สร้าง node ต่อ transaction และวาด edge Ti→Tj ถ้า operation ของ Ti มาก่อนและ conflict กับ Tj บน item เดียวกัน ถ้ากราฟไม่มี cycle schedule เป็น conflict-serializable และ topological order ให้ serial order ที่เทียบเท่า ถ้ามี cycle ไม่มีทางสลับ non-conflicting operation ให้กลายเป็น serial schedule ได้

1. เขียน schedule พร้อม transaction ID และ data item
2. หา conflict ทุกคู่ตามลำดับที่เกิด
3. วาด edge จาก operation ก่อนหน้าไป transaction หลัง
4. ตรวจ cycle และอธิบาย ไม่ใช่เดาจากหน้าตาว่าสลับเยอะ

Serializability ไม่เท่ากับลำดับเวลาจริงเสมอ

Serializability ต้องการผลเทียบเท่า serial order หนึ่ง แต่ไม่ได้บังคับว่า transaction ที่เริ่มหรือจบก่อนในโลกจริงต้องมาก่อนเสมอ Strict serializability เพิ่ม real-time order เข้าไป ถ้า T1 จบก่อน T2 เริ่ม ทุกคนต้องเห็น T1 ก่อน T2 แนวคิดนี้สำคัญใน distributed database ที่ต้องอธิบาย guarantee ต่อผู้ใช้

9Anomaly มากกว่า Dirty Read และ Lost Update

Write Skew: กับดักของ Snapshot Isolation

สมมุติต้องมีแพทย์เวรอย่างน้อยหนึ่งคน Alice และ Bob อยู่เวร ทั้งคู่ต้องการลา แต่ละ transaction อ่าน snapshot ว่าอีกคนยังอยู่จึงแก้ row ของตนเป็นลา ทั้งคู่เขียนคนละ row ไม่มี write–write conflict จึง commit ได้ ผลสุดท้ายไม่มีใครอยู่เวรและ invariant เสีย

Snapshot Isolation ป้องกัน anomaly จำนวนมากและให้ read concurrency ดี แต่ไม่เท่ากับ serializable ทุกกรณี การป้องกัน write skew อาจใช้ serializable isolation, explicit lock บนสิ่งแทน invariant, materialized constraint หรือออกแบบข้อมูลให้ conflict บน row เดียวกัน

10Locking แบบที่ระบบจริงต้องตัดสินใจ

Shared/Exclusive lock เป็นจุดเริ่ม แต่ระบบจริงต้องเลือก granularity ถ้าล็อกทั้ง table overhead ต่ำแต่ concurrency ต่ำ ถ้าล็อกทีละ row concurrency สูงแต่มี lock จำนวนมาก และ predicate/range query อาจต้องป้องกัน phantom ด้วย range/index lock

Two-Phase Locking กับ Strictness

Basic 2PL รับประกัน conflict serializability โดยมี growing/shrinking phase แต่ถ้าปล่อย write lock ก่อน commit transaction อื่นอาจอ่านค่าที่ยัง rollback ได้และเกิด cascading abort Strict 2PL ถือ exclusive lock ถึง commit/abort ส่วน rigorous 2PL ถือทั้ง shared และ exclusive ถึงจบ ทำ recovery reasoning ง่ายขึ้นแต่เพิ่มเวลาถือ lock

Deadlock เป็นผลจากนโยบายรอ ไม่ใช่ Bug แปลกประหลาด

ถ้า T1 lock A รอ B และ T2 lock B รอ A เกิดวงจรใน wait-for graph แนวทางมีสามกลุ่ม: ป้องกันด้วย ordering/preclaim, หลีกเลี่ยงด้วย timestamp policy เช่น wait-die/wound-wait หรือยอมให้เกิดแล้ว detect cycle/เลือก victim

การเลือก victim ควรดู work ที่ทำไป จำนวน lock, rollback cost, อายุ และ starvation Transaction ที่ถูก abort ซ้ำต้องมี priority/backoff ไม่เช่นนั้นระบบ technically เดินหน้าได้แต่ผู้ใช้รายหนึ่งไม่มีวันสำเร็จ

11Optimistic Concurrency Control: เดิมพันว่า Conflict น้อย

OCC ให้ transaction ทำงานบน tentative state แล้ว validate ก่อน commit จึงไม่มี lock wait ระหว่าง working phase เหมาะกับ read-heavy, transaction สั้น และ conflict ต่ำ แต่เมื่อ contention สูง งานจำนวนมากทำเกือบเสร็จแล้ว abort ทำให้ทรัพยากรถูกใช้ซ้ำ

คำว่า optimistic ไม่ได้แปลว่ามองโลกดี แต่เป็นสมมติฐานเชิง workload ว่า conflict rare พอให้ตรวจทีหลังคุ้ม ส่วน pessimistic ยอมจ่าย waiting ล่วงหน้าเพื่อไม่ให้ทำงานที่ต้องทิ้ง ไม่มีวิธีใดดีกว่าโดยไม่รู้ conflict rate และ cost ของ retry

Version Column ใน Web Application

UPDATE documents
SET body = :new_body, version = version + 1
WHERE id = :id AND version = :version_read;

ถ้า affected rows เป็น 0 แปลว่ามีคนแก้หลังจากเราอ่าน Application ต้องเลือกแจ้ง conflict, merge หรือโหลดใหม่ ไม่ควรเขียนทับเงียบ ๆ นี่คือ OCC แบบที่เห็นได้ใน API ด้วย ETag/If-Match

12Timestamp Ordering และเวลาที่ไม่ได้แปลว่านาฬิกาผนัง

Timestamp ordering กำหนด serial order จาก timestamp ของ transaction แล้วตรวจ read/write ให้ไม่ละเมิดลำดับ Timestamp ในที่นี้เป็น logical order ได้ ไม่จำเป็นต้องเป็นเวลาจริง ทุก data item เก็บ read timestamp และ write timestamp เพื่อรู้ว่า operation ใหม่มาช้าหรือเร็วเกินลำดับที่กำหนด

ข้อดีคือไม่มี deadlock เพราะ transaction ไม่รอ lock แต่ conflict ทำให้ abort และ restart ได้มาก โดยเฉพาะ transaction เก่าที่ช้าถูก transaction ใหม่แซง Thomas Write Rule อาจละทิ้ง obsolete write บางกรณีโดยไม่ abort แต่ต้องวิเคราะห์ semantics ให้ถูก

13MVCC: หลายเวอร์ชันเพื่อให้การอ่านไม่ขวางการเขียน

MVCC เก็บ row หลายเวอร์ชันพร้อม metadata ว่า version ใดมองเห็นสำหรับ snapshot ของ transaction Reader เลือก version ที่เหมาะแทนรอ writer ทำให้ read concurrency สูง แต่ไม่ได้แปลว่าไม่มี lock เลย Writer ยัง conflict กัน และ metadata/version เก่าต้อง vacuum/garbage collect

Isolation Level เป็น Contract ไม่ใช่ปุ่มความเร็ว

ระดับต่ำกว่ายอม anomaly บางชนิดเพื่อ concurrency แต่ application ต้องรับผลได้ อย่าเลือก Read Committed เพราะ default แล้วสมมุติ transaction ทั้งหมด serializable ในทางกลับกัน Serializable อาจ abort transaction ด้วย serialization failure ซึ่ง application ต้อง retry ทั้ง transaction อย่างถูกต้อง

ชื่อ level มีรายละเอียดต่างกันตาม database เช่น Repeatable Read ของ PostgreSQL ใกล้ snapshot isolation ขณะที่ implementation อื่นต่างออกไป ต้องอ่านเอกสารระบบจริงและทดสอบ anomaly ไม่ใช้ชื่อมาตรฐานอย่างเดียวอนุมาน guarantee

14Concurrency Control ข้าม Process กับข้าม Service

บทนี้เน้น database/site เดียวเป็นฐาน ก่อนบท Distributed Transactions แต่ application สมัยใหม่มักเผลอแบ่ง invariant ข้าม service เช่น Order กับ Inventory อยู่คนละฐานข้อมูล Lock ในฐานหนึ่งไม่ครอบอีกฐาน การเรียกสอง API ต่อกันจึงไม่เป็น transaction เดียวโดยธรรมชาติ

ถ้าต้อง consistency ทันที อาจใช้ distributed transaction/2PC โดยยอม coordination และ availability cost ถ้ายอมขั้นกลางได้ ใช้ Saga/compensation แต่ต้องนิยาม state intermediate และ action ที่ย้อนกลับไม่ได้ สิ่งสำคัญคือไม่เรียก workflow หลาย service ว่า ACID transaction หากไม่มี protocol ที่รับประกันจริง

15Workshop: ทำให้ Anomaly เกิดก่อนแก้

ใช้ PostgreSQL/MySQL หรือฐานข้อมูลที่เข้าถึงได้ เปิดสอง session และทำการทดลองทีละขั้น การเห็น anomaly จริงช่วยแยกสิ่งที่ฐานข้อมูลรับประกันจากสิ่งที่เราคิดว่า transaction ควรทำ

1. สร้างบัญชี A/B และตารางแพทย์เวร พร้อม constraint พื้นฐาน
2. ทำ lost update ด้วย read–compute–write จากสอง session
3. แก้ด้วย atomic update และเปรียบเทียบกับ SELECT FOR UPDATE
4. ทดลอง non-repeatable read ภายใต้ Read Committed
5. ทดลอง snapshot เดิมภายใต้ Repeatable Read
6. สร้าง write skew แพทย์เวร แล้วทดลอง Serializable
7. สร้าง deadlock โดย lock A/B สลับลำดับ จด error และ victim
8. เพิ่ม version column ทำ OCC แล้วทดสอบ conflict
9. วัด workload conflict ต่ำ/สูง เปรียบเทียบ waiting กับ abort rate

16แนวทางเลือกกลไกโดยไม่เริ่มจากความชอบ

1. เขียน invariant และ anomaly ที่ยอมรับไม่ได้ก่อน
2. ระบุขอบเขตข้อมูล: row, table, database หรือหลาย service
3. วัด read/write ratio, conflict distribution, transaction duration และ hot key
4. เลือก isolation/control ที่ป้องกัน anomaly ด้วยต้นทุนต่ำสุดที่รับได้
5. ออกแบบ retry สำหรับ deadlock/serialization failure ให้ทั้ง transaction และ idempotent
6. ทดสอบ concurrent schedule ไม่ใช่ unit test ทีละ request
7. monitor lock wait, abort rate, long transaction, version bloat และ tail latency

17สรุปและขั้นตอนถัดไป

Concurrency Control เริ่มจาก invariant และ schedule ไม่ใช่เริ่มจากเลือก lock ACID แยกความรับผิดชอบหลายด้าน โดย Isolation ทำให้ผลของงานพร้อมกันมีความหมายเสมือน serial order ระดับหนึ่ง แต่ isolation level ที่ต่ำกว่า Serializable ยอม anomaly บางชนิดและ application ต้องรู้

Locking จ่ายด้วย waiting/deadlock, OCC จ่ายด้วย validation/abort, timestamp ordering จ่ายด้วย restart เมื่อผิดลำดับ และ MVCC จ่ายด้วยหลายเวอร์ชัน/cleanup การเลือกต้องสัมพันธ์กับ contention และ invariant ระบบที่เร็วเพราะไม่ตรวจ conflict อาจเพียงผลิตข้อมูลผิดได้เร็วขึ้น ซึ่งไม่นับเป็น scalability ที่น่าภูมิใจนัก

ขั้นตอนถัดไปคือ Distributed Transactions เมื่อ atomic action ต้องข้ามหลาย process และหลายฐานข้อมูล เราจะพบว่า lock และ commit ภายใน site เดียวไม่พอ ต้องมี protocol ให้ participant ตกลงผลร่วมกัน ทั้งที่ coordinator หรือ network อาจล้มกลางทาง นั่นคือจุดที่ correctness เริ่มแลกกับ availability และเวลารออย่างชัดเจนขึ้น