เมื่อจัดการกับความขัดแย้งคุณมีสองตัวเลือก:
- คุณสามารถพยายามหลีกเลี่ยงความขัดแย้งและนั่นคือสิ่งที่การมองโลกในแง่ร้ายทำ
- หรือคุณอาจยอมให้มีความขัดแย้งเกิดขึ้น แต่คุณต้องตรวจสอบเมื่อทำธุรกรรมของคุณและนั่นคือสิ่งที่ Optimistic Locking ทำ
ตอนนี้มาลองพิจารณาความผิดปกติที่หายไปของ Updateต่อไปนี้:
ความผิดปกติที่หายไปของการอัปเดตสามารถเกิดขึ้นได้ในระดับการแยกแบบมุ่งมั่นที่อ่านแล้ว
ในแผนภาพด้านบนเราจะเห็นว่าอลิซเชื่อว่าเธอสามารถถอนได้ 40 จากเธอaccountแต่ไม่ทราบว่าบ็อบเพิ่งเปลี่ยนยอดเงินในบัญชีและตอนนี้เหลือเพียง 20 บัญชีในบัญชีนี้
การล็อคในแง่ร้าย
การล็อคในแง่ร้ายบรรลุเป้าหมายนี้โดยการแชร์หรือล็อกการอ่านในบัญชีเพื่อป้องกันไม่ให้บ็อบเปลี่ยนบัญชี
ในแผนภาพด้านบนทั้งอลิซและบ็อบจะได้รับล็อกการอ่านในaccountแถวของตารางที่ผู้ใช้ทั้งสองได้อ่าน ฐานข้อมูลได้รับการล็อคเหล่านี้บน SQL Server เมื่อใช้ Repeatable Read หรือ Serializable
เนื่องจากทั้งอลิซและบ๊อบได้อ่านaccountด้วยค่า PK ของ1ทั้งคู่จึงไม่สามารถเปลี่ยนได้จนกว่าผู้ใช้รายหนึ่งจะปลดล็อกการอ่าน นี่เป็นเพราะการดำเนินการเขียนต้องได้รับการล็อกแบบล็อก / แบบเอกสิทธิ์เฉพาะบุคคลและการล็อกแบบแบ่งใช้ / การอ่านป้องกันการเขียนแบบเอกสิทธิ์ / ล็อค
หลังจากที่อลิซได้ทำธุรกรรมของเธอแล้วและล็อคการอ่านได้เปิดตัวในaccountแถวนั้นบ๊อบUPDATEจะกลับมาทำงานต่อและใช้การเปลี่ยนแปลงนั้น จนกว่าอลิซจะปลดล็อคการอ่านบล็อกของ UPDATE ของบ็อบ
สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับวิธีการเข้าถึงข้อมูลกรอบใช้ฐานข้อมูลสนับสนุนการล็อคพื้นฐานในแง่ร้าย, ตรวจสอบบทความนี้
การล็อคในแง่ดี
การล็อกในแง่ดีช่วยให้เกิดความขัดแย้ง แต่ตรวจพบเมื่อใช้ UPDATE ของอลิซเมื่อมีการเปลี่ยนแปลงเวอร์ชัน
เวลานี้เรามีversionคอลัมน์เพิ่มเติม versionคอลัมน์จะเพิ่มขึ้นทุกครั้งที่มีการปรับปรุงหรือลบจะถูกดำเนินการและมันก็ยังใช้ในคำสั่ง WHERE ของปรับปรุงและลบงบ เพื่อให้สามารถใช้งานได้เราจะต้องเลือก SELECT และอ่านปัจจุบันversionก่อนที่จะดำเนินการ UPDATE หรือ DELETE ไม่เช่นนั้นเราจะไม่ทราบว่าค่ารุ่นใดที่จะส่งผ่านไปยังส่วนคำสั่ง WHERE หรือส่วนเพิ่ม
สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับวิธีการเข้าถึงข้อมูลกรอบการดำเนินการล็อคในแง่ดี, ตรวจสอบบทความนี้
ธุรกรรมระดับแอปพลิเคชัน
ระบบฐานข้อมูลเชิงสัมพันธ์ได้เกิดขึ้นในช่วงปลายยุค 70 ต้นยุค 70 เมื่อลูกค้าต้องการเชื่อมต่อกับเมนเฟรมผ่านเทอร์มินัล นั่นเป็นเหตุผลที่เรายังคงเห็นระบบฐานข้อมูลกำหนดเงื่อนไขเช่นการตั้งค่า SESSION
ทุกวันนี้บนอินเทอร์เน็ตเราจะไม่ทำการอ่านและเขียนอีกต่อไปในบริบทของธุรกรรมฐานข้อมูลเดียวกันและ ACID นั้นไม่เพียงพออีกต่อไป
ตัวอย่างเช่นพิจารณากรณีการใช้งานต่อไปนี้:
หากไม่มีการล็อกในแง่ดีจะไม่มีทางที่ Lost Update นี้จะถูกตรวจจับแม้ว่าธุรกรรมฐานข้อมูลจะใช้ Serializable นี่เป็นเพราะการอ่านและเขียนถูกดำเนินการในคำขอ HTTP ที่แยกต่างหากดังนั้นในธุรกรรมฐานข้อมูลที่แตกต่างกัน
ดังนั้นการล็อกในแง่ดีสามารถช่วยคุณป้องกันการอัพเดทที่หายไปได้แม้ว่าจะใช้ธุรกรรมระดับแอปพลิเคชันที่รวมเวลาที่ผู้ใช้คิดเช่นกัน
สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับการสมัครระดับการทำธุรกรรมหรือตรรกะตรวจสอบบทความนี้
ข้อสรุป
การล็อก Optimistic เป็นเทคนิคที่มีประโยชน์มากและใช้งานได้ดีแม้ว่าจะใช้ระดับการแยกที่เข้มงวดน้อยกว่าเช่น Read Committed หรือเมื่อการอ่านและเขียนถูกเรียกใช้งานในฐานข้อมูลที่ตามมา
ข้อเสียของการล็อคในแง่ดีคือการย้อนกลับจะถูกทริกเกอร์โดยกรอบการเข้าถึงข้อมูลเมื่อมีการจับOptimisticLockExceptionดังนั้นจึงสูญเสียงานทั้งหมดที่เราเคยทำก่อนหน้านี้โดยการทำธุรกรรมการดำเนินการในปัจจุบัน
ความขัดแย้งมากขึ้นและโอกาสในการยกเลิกการทำธุรกรรมมากขึ้น การย้อนกลับอาจมีค่าใช้จ่ายสูงสำหรับระบบฐานข้อมูลเนื่องจากจำเป็นต้องยกเลิกการเปลี่ยนแปลงที่ค้างอยู่ปัจจุบันทั้งหมดซึ่งอาจเกี่ยวข้องกับทั้งแถวของตารางและเรคคอร์ดดัชนี
ด้วยเหตุนี้การล็อคในแง่ร้ายอาจเหมาะสมกับแร่เมื่อเกิดความขัดแย้งเกิดขึ้นบ่อยครั้งเนื่องจากช่วยลดโอกาสในการทำธุรกรรมย้อนกลับ