Concurency Control: Recoverability และ Isolation

สำหรับ concurrent transaction และมีบาง transaction fail ซึ่งอาจจะมีผลลัพธ์ที่กระทบกับ transaction ที่ commit ไปแล้วให้ไม่ถูกต้อง ซึ่ง transaction นั้นๆ ก็ควรจะ recover กลับมาด้วย เช่น

T1	T2
read(A)
write(A)
	read(A)
read(B)
...
failed

เมื่อ T1 fail ก็จะทำการ roll back T1 ดังนั้นค่าที่ T2 นำไปใช้จึงเป็นค่าที่ไม่ถูกต้อง และควรจะต้องถูก roll back ด้วย หรือที่เรียกว่า มี recoverability แต่การทำ roll back ย้อยกลับไป (ซึ่งเรียกว่า Cascade Schedule) ดังนี้ จะทำให้เสียเวลาอย่างมาก ดังนั้นจึงมีความคิดในเรื่องการทำเป็น Cascadeless Schedules

Cascadeless Schedule คือการจะ read ค่าใด จะต้องรอให้ transaction ที่มีการ write ค่านั้นๆ commit ให้เสร็จสิ้นก่อน แต่ก็จะทำให้การทำงานของ transaction ช้าลง เนื่องจากต้องรออีก transaction หนึ่งทำงาน ดังนั้น DBMS จึงเปิดให้มีการกำหนดลักษณะการทำงานนี้โดย DBA เอง ที่เรียกว่า Level of Consistency ในมาตรฐาน SQL-92 หรือ Isolation level ดังนี้
1. Serializable คือการรับประกันของ DBMS ที่รองรับ Conflict Serializable + View Serializable + Cascadeless Scheduler + ไม่เกิดปัญหา Phantom phenomenon
หรือเรียกว่าแก้ปัญหา lost update + uncommitted dependency +inconsistent analysis + phantom phenomenon
2. Repeatable read คล้ายกับ Serializable แต่ไม่รองรับปัญหา Phantom phenomenon แต่สำหรับบาง product เช่น DB2 หรือ Infomix ไม่มี Serializable ให้เลือก แต่ที่ Repeatable read สามารถรองรับ Phantom phenomenon ด้วย
หรือเรียกว่าแก้ปัญหา lost update + uncommitted dependency +inconsistent analysis
3. Read committed หรือ Oracle เรียกว่า Snapshot read รองรับแค่ Cascadeless schedule
หรือเรียกว่า แก้ปัญหาเฉพาะ uncommitted dependency
4. Read uncommitted หรือ Cursor Stability หรือ Dirty read จะไม่รองรับ concurrency control problem ใดๆ