การล็อกเชิงมองโลกแง่ดีสำหรับเครื่องมือแอดมิน: ป้องกันการเขียนทับเงียบ

ปัญหา: การเขียนทับเงียบเมื่อหลายคนแก้ไข

“การเขียนทับเงียบ” เกิดขึ้นเมื่อสองคนเปิดเรคอร์ดเดียวกัน แก้ไขทั้งคู่ และคนที่คลิกบันทึกทีหลังก็เป็นผู้ชนะ การแก้ไขของคนแรกหายไปโดยไม่มีคำเตือนและบ่อยครั้งไม่มีวิธีกู้คืนที่ง่าย

ในแผงแอดมินที่คนใช้หนาแน่น ปัญหานี้เกิดขึ้นทั้งวันโดยไม่มีใครสังเกต ผู้คนเปิดหลายแท็บ กระโดดไปมาระหว่างตั๋ว แล้วกลับมาที่ฟอร์มที่ค้างไว้ 20 นาที เมื่อพวกเขาบันทึกในที่สุด พวกเขาไม่ได้อัปเดตเวอร์ชันล่าสุดของเรคอร์ด แต่กำลังเขียนทับมัน

เรื่องนี้พบได้บ่อยกว่าในเครื่องมือหลังบ้านมากกว่าแอปสาธารณะ เพราะงานเป็นแบบร่วมมือและอิงเรคอร์ด ทีมภายในจะแก้ไขลูกค้า คำสั่งสินค้า และคำขอเดียวกันซ้ำ ๆ ในช่วงสั้น ๆ แอปสาธารณะมักเป็น “ผู้ใช้คนเดียวแก้ไขข้อมูลของตัวเอง” ในขณะที่เครื่องมือแอดมินคือ “หลายคนแก้ไขของที่แชร์กัน”

ผลเสียอาจไม่ร้ายแรงทันที แต่มันสะสมเร็ว:

• ราคาสินค้าถูกเปลี่ยนกลับเป็นค่าก่อนหน้า หลังจากอัปเดตโปรโมชั่น
• หมายเหตุภายในของเจ้าหน้าที่สนับสนุนหายไป ทำให้เจ้าหน้าที่คนถัดไปต้องทำซ้ำการแก้ไขปัญหา
• สถานะคำสั่งเปลี่ยนกลับ (เช่น จาก “Shipped” เป็น “Packed”) ทำให้เกิดการติดตามที่ผิด
• เบอร์โทรหรือที่อยู่ลูกค้าถูกแทนที่ด้วยข้อมูลล้าสมัย

การเขียนทับเงียบเจ็บปวดเพราะทุกคนคิดว่าระบบบันทึกเรียบร้อย ไม่มีช่วงเวลา "เกิดข้อผิดพลาด" ชัดเจน แค่ความสับสนทีหลังเมื่อรายงานผิดปกติหรือเพื่อนร่วมงานถามว่า “ใครเปลี่ยนตรงนี้?”

ความขัดแย้งแบบนี้เป็นเรื่องปกติ พวกมันบอกว่าเครื่องมือถูกใช้ร่วมกันและมีประโยชน์ ไม่ใช่ว่าทีมของคุณทำอะไรผิด เป้าหมายไม่ใช่ป้องกันไม่ให้สองคนแก้ไข แต่เพื่อจับว่าเรคอร์ดถูกเปลี่ยนระหว่างที่คนกำลังแก้ไข แล้วจัดการช่วงเวลานั้นอย่างปลอดภัย

ถ้าคุณกำลังสร้างเครื่องมือภายในบนแพลตฟอร์มแบบ no-code เช่น AppMaster ควรวางแผนเรื่องนี้แต่แรก เครื่องมือแอดมินเติบโตเร็ว และเมื่อทีมพึ่งพามัน การสูญเสียข้อมูลเป็น "บางครั้ง" จะกลายเป็นแหล่งความไม่ไว้วางใจเรื้อรัง

การล็อกเชิงมองโลกแง่ดี (Optimistic locking) อธิบายแบบเข้าใจง่าย

เมื่อสองคนเปิดเรคอร์ดเดียวกันและทั้งคู่กดบันทึก คุณมีสภาพการทำงานพร้อมกัน (concurrency) ทุกคนเริ่มจากสแน็ปช็อตเก่า แต่มีเพียงหนึ่งคนที่จะเป็น "ล่าสุด" เมื่อการบันทึกเกิดขึ้น

ถ้าไม่มีการป้องกัน การบันทึกครั้งสุดท้ายจะชนะ นั่นคือวิธีที่เกิดการเขียนทับเงียบ: การบันทึกครั้งที่สองแทนที่การเปลี่ยนแปลงของคนแรกโดยเงียบ ๆ

Optimistic locking คือกฎง่าย ๆ ว่า: “ฉันจะบันทึกก็ต่อเมื่อเรคอร์ดยังอยู่ในสถานะเดียวกับตอนที่ฉันเริ่มแก้ไข” ถ้าเรคอร์ดถูกเปลี่ยนไปแล้ว การบันทึกจะถูกปฏิเสธและผู้ใช้จะเห็นความขัดแย้ง

ต่างจาก pessimistic locking ซึ่งใกล้เคียงกับ “ฉันกำลังแก้ไข ดังนั้นไม่มีใครอื่นทำได้” Pessimistic locking มักมีการล็อกจริง เวลาออก และผู้คนถูกบล็อก มันอาจจำเป็นในกรณีพิเศษ (เช่น ย้ายเงินระหว่างบัญชี) แต่โดยทั่วไปมักทำให้หงุดหงิดในเครื่องมือแอดมินที่มีการแก้ไขเล็ก ๆ น้อย ๆ ตลอดวัน

Optimistic locking มักเป็นค่าเริ่มต้นที่ดีกว่าเพราะช่วยให้การทำงานไหลลื่น ผู้คนสามารถแก้ไขพร้อมกันได้ และระบบจะเข้าแทรกเมื่อเกิดการชนจริง ๆ เท่านั้น

มันเหมาะเมื่อ:

• ความขัดแย้งเป็นไปได้แต่ไม่บ่อย
• การแก้ไขเร็ว (ไม่กี่ฟิลด์ ฟอร์มสั้น)
• การบล็อกผู้อื่นจะทำให้ทีมช้าลง
• คุณสามารถแสดงข้อความชัดเจนว่า “มีคนอัปเดตสิ่งนี้”
• API ของคุณสามารถตรวจสอบเวอร์ชัน (หรือ timestamp) ทุกครั้งที่อัปเดต

สิ่งที่มันป้องกันคือปัญหา "การเขียนทับเงียบ" แทนที่จะสูญเสียข้อมูล คุณจะได้การหยุดที่ชัดเจน: “เรคอร์ดนี้ถูกเปลี่ยนตั้งแต่คุณเปิดมัน”

สิ่งที่มันทำไม่ได้ก็สำคัญเช่นกัน มันจะไม่หยุดสองคนตัดสินใจแตกต่างกันจากข้อมูลเก่า และมันไม่สามารถรวมการเปลี่ยนแปลงให้โดยอัตโนมัติได้ และถ้าคุณข้ามการตรวจสอบฝั่งเซิร์ฟเวอร์ คุณก็ยังไม่ได้แก้ปัญหาจริง ๆ

ขีดจำกัดทั่วไปที่ต้องจำ:

• มันจะไม่แก้ความขัดแย้งโดยอัตโนมัติ (คุณยังต้องมีทางเลือก)
• มันจะไม่ช่วยหากผู้ใช้แก้ไขแบบออฟไลน์แล้วซิงค์ทีหลังโดยไม่มีการตรวจสอบ
• มันจะไม่แก้ปัญหาสิทธิ์ที่ผิด (คนยังสามารถแก้สิ่งที่ไม่ควรแก้ได้)
• มันจะไม่จับความขัดแย้งถ้าคุณตรวจเฉพาะฝั่งไคลเอนต์

ในทางปฏิบัติ optimistic locking เป็นแค่ค่าพิเศษที่ส่งมาพร้อมการแก้ไข บวกกับกฎฝั่งเซิร์ฟเวอร์ที่ว่า “อัปเดตเท่านั้นถ้าตรงกัน” หากคุณสร้างแผงแอดมินใน AppMaster การตรวจสอบนี้มักอยู่ใน Business Logic ที่ทำการอัปเดต

สองวิธีที่พบบ่อย: คอลัมน์เวอร์ชัน เทียบกับ updated_at

เพื่อจับว่าเรคอร์ดเปลี่ยนไปในระหว่างการแก้ไข มักเลือกสัญญาณสองอย่าง: ตัวเลขเวอร์ชัน หรือ updated_at timestamp

วิธีที่ 1: คอลัมน์เวอร์ชัน (จำนวนเต็มเพิ่มขึ้น)

เพิ่มฟิลด์ version (มักเป็นจำนวนเต็ม) เมื่อตอนโหลดฟอร์มแก้ไข ให้โหลด version ปัจจุบันด้วย เมื่อต้องการบันทึก ให้ส่งค่านั้นกลับ

การอัปเดตจะสำเร็จเฉพาะเมื่อค่า version ที่เก็บตรงกับค่าที่ผู้ใช้เริ่มต้นไว้ ถ้าตรง คุณอัปเดตเรคอร์ดและเพิ่ม version ทีละ 1 ถ้าไม่ตรง ให้คืนความขัดแย้งแทนการเขียนทับ

วิธีนี้คิดง่าย: เวอร์ชัน 12 หมายถึง “นี่คือการเปลี่ยนแปลงครั้งที่ 12” และหลีกเลี่ยงกรณีขอบที่เกี่ยวกับเวลา

วิธีที่ 2: updated_at (เปรียบเทียบ timestamp)

ตารางส่วนใหญ่มีฟิลด์ updated_at อยู่แล้ว แนวคิดเหมือนกัน: อ่าน updated_at เมื่อฟอร์มเปิด แล้วรวมมันกับการบันทึก เซิร์ฟเวอร์จะอัปเดตเฉพาะเมื่อ updated_at ไม่เปลี่ยน

มันทำงานได้ดี แต่ timestamp มีข้อควรระวัง ฐานข้อมูลต่าง ๆ เก็บความละเอียดต่างกัน บางที่ปัดเป็นวินาที ซึ่งอาจพลาดการแก้ไขที่เร็วมาก หากหลายระบบเขียนเข้าฐานข้อมูลเดียวกัน ความเพี้ยนของนาฬิกาและการจัดการโซนเวลาก็อาจสร้างปัญหาได้

สรุปง่าย ๆ:

• คอลัมน์เวอร์ชัน: พฤติกรรมชัดเจน ใช้ได้ทุกฐานข้อมูล ไม่มีปัญหาเรื่องนาฬิกา
• updated_at: มัก “ฟรี” เพราะมีอยู่แล้ว แต่ความละเอียดและการจัดการเวลาอาจก่อปัญหา

สำหรับทีมส่วนใหญ่ คอลัมน์เวอร์ชันเป็นสัญญาณหลักที่ดีกว่า ชัดเจน คาดเดาได้ และอ้างอิงได้ง่ายในบันทึกหรือการสนับสนุน

ถ้าคุณสร้างใน AppMaster นั่นหมายถึงเพิ่มฟิลด์ version แบบ integer ใน Data Designer และให้แน่ใจว่าโลจิกการอัปเดตจะตรวจสอบมันก่อนบันทึก คุณยังคงเก็บ updated_at เพื่อการตรวจสอบประวัติ แต่ให้หมายเลขเวอร์ชันเป็นตัวตัดสินว่าการแก้ไขปลอดภัยหรือไม่

ควรเก็บอะไรและส่งอะไรพร้อมการแก้ไขแต่ละครั้ง

Optimistic locking จะทำงานได้ก็ต่อเมื่อการแก้ไขทุกครั้งมีตัวชี้ว่า "เห็นล่าสุดเมื่อ" ซึ่งอาจเป็น version หรือ updated_at ถ้าไม่มี เซิร์ฟเวอร์จะไม่สามารถทราบได้ว่าเรคอร์ดเปลี่ยนไปขณะผู้ใช้พิมพ์หรือไม่

บนเรคอร์ด ให้เก็บฟิลด์ธุรกิจปกติ พร้อมฟิลด์ concurrency หนึ่งตัวที่เซิร์ฟเวอร์ควบคุม ชุดขั้นต่ำคือ:

• id (ตัวระบุคงที่)
• ฟิลด์ธุรกิจ (name, status, price, notes, ฯลฯ)
• version (integer เพิ่มขึ้นเมื่ออัปเดตสำเร็จ) หรือ updated_at (timestamp เซิร์ฟเวอร์เขียน)

เมื่อหน้าจอแก้ไขโหลด ฟอร์มต้องเก็บค่าสัญญาณ concurrency ที่เห็นล่าสุดไว้ ผู้ใช้ไม่ควรแก้ไขมัน ให้เก็บเป็นฟิลด์ซ่อนหรือในสถานะของฟอร์ม ตัวอย่าง: API ส่ง version: 12 แล้วฟอร์มเก็บ 12 จนกว่าจะกด Save

เมื่อผู้ใช้คลิก Save ให้ส่งสองสิ่ง: การเปลี่ยนแปลงและตัวชี้ที่เห็นล่าสุด รูปร่างง่ายที่สุดคือใส่ใน body ของคำขออัปเดต เช่น id, ฟิลด์ที่เปลี่ยน และ expected_version (หรือ expected_updated_at) ถ้าคุณสร้าง UI ใน AppMaster ปฏิบัติกับค่านี้เหมือนค่าที่ผูกกับฟอร์ม: โหลดมันกับเรคอร์ด เก็บไว้ไม่เปลี่ยน แล้วส่งกลับกับการอัปเดต

ฝั่งเซิร์ฟเวอร์ การอัปเดตต้องเป็นแบบมีเงื่อนไข เฉพาะเมื่อ expected marker ตรงกับค่าปัจจุบันในฐานข้อมูลเท่านั้น ถ้าไม่ตรง อย่า “รวม” แบบเงียบ ๆ

การตอบกลับความขัดแย้งควรชัดเจนและง่ายต่อการจัดการใน UI การตอบกลับที่ใช้ได้จริงรวมถึง:

• HTTP status 409 Conflict
• ข้อความสั้น ๆ เช่น “เรคอร์ดนี้ถูกอัปเดตโดยคนอื่นแล้ว”
• ค่าปัจจุบันจากเซิร์ฟเวอร์ (current_version หรือ current_updated_at)
• ตัวเรคอร์ดปัจจุบันจากเซิร์ฟเวอร์ (ถ้าเป็นไปได้ เพื่อให้ UI แสดงการเปลี่ยนแปลง)

ตัวอย่าง: Sam เปิด Customer ที่เวอร์ชัน 12 Priya บันทึกเป็นเวอร์ชัน 13 Sam พยายามบันทึกด้วย expected_version: 12 เซิร์ฟเวอร์คืน 409 พร้อมเรคอร์ดเวอร์ชัน 13 ตอนนี้ UI สามารถแจ้ง Sam ให้ทบทวนค่าแทนการเขียนทับการแก้ไขของ Priya

ขั้นตอนทีละขั้น: การใช้งาน optimistic locking ครบวงจร

การล็อกเชิงมองโลกแง่ดีส่วนใหญ่สรุปได้เป็นกฎเดียว: การแก้ไขทุกครั้งต้องพิสูจน์ว่ามันอิงกับเวอร์ชันล่าสุดของเรคอร์ด

1) เพิ่มฟิลด์ concurrency

เลือกฟิลด์ตัวเดียวที่เปลี่ยนทุกครั้งที่เขียน

version แบบจำนวนเต็มเฉพาะทำให้อ่านง่าย เริ่มที่ 1 แล้วเพิ่มทุกอัปเดต หากคุณมี updated_at ที่เชื่อถือได้และเปลี่ยนทุกครั้งก็สามารถใช้ได้ แต่ให้แน่ใจว่ามันอัปเดตทุกการเขียน (รวมงานแบ็กกราวด์ด้วย)

2) ส่งค่านั้นให้ไคลเอนต์เมื่ออ่าน

เมื่อ UI เปิดหน้าจอแก้ไข ให้รวม version (หรือ updated_at) ปัจจุบันในคำตอบ เก็บมันในสถานะของฟอร์มเหมือนใบเสร็จที่บอกว่า “ฉันกำลังแก้ไขข้อมูลที่ฉันอ่านล่าสุดนี้”

3) ต้องมีค่านั้นเมื่ออัปเดต

เมื่อบันทึก ไคลเอนต์ส่งฟิลด์ที่แก้ไขพร้อมค่าความคาดหวังของ concurrency

ฝั่งเซิร์ฟเวอร์ ให้การอัปเดตเป็นแบบมีเงื่อนไข ตัวอย่าง SQL:

UPDATE tickets
SET status = $1,
    version = version + 1
WHERE id = $2
  AND version = $3;

ถ้าอัปเดต 1 แถว แสดงว่าบันทึกสำเร็จ ถ้า 0 แถว แสดงว่าใครบางคนแก้ไขเรคอร์ดไปแล้ว

4) คืนค่าค่าใหม่หลังบันทึกสำเร็จ

หลังบันทึกสำเร็จ ให้คืนเรคอร์ดที่อัปเดตพร้อม version ใหม่ (หรือ updated_at ใหม่) ไคลเอนต์ควรแทนที่สถานะฟอร์มด้วยค่าที่เซิร์ฟเวอร์คืน นี่ช่วยป้องกันการบันทึกซ้ำโดยใช้เวอร์ชันเก่า

5) ถือว่าความขัดแย้งเป็นผลลัพธ์ปกติ

เมื่อการอัปเดตแบบมีเงื่อนไขล้มเหลว ให้คืนการตอบสนองความขัดแย้งที่ชัดเจน (มักเป็น 409) ซึ่งรวมถึง:

• เรคอร์ดปัจจุบัน
• การเปลี่ยนแปลงที่ไคลเอนต์พยายามทำ (หรือข้อมูลพอจะสร้างมันขึ้นมาได้)
• ฟิลด์ที่ต่างกัน (ถ้าคำนวณได้)

ใน AppMaster นี่สอดคล้องกับฟิลด์รุ่นใน Data Designer, endpoint อ่านที่ส่งเวอร์ชัน และ Business Process ที่ทำการอัปเดตแบบมีเงื่อนไขแล้วแตกกรณีเป็นสำเร็จหรือความขัดแย้ง

รูปแบบ UI ที่จัดการความขัดแย้งโดยไม่รบกวนผู้ใช้

Optimistic locking เป็นแค่ครึ่งหนึ่ง อีกครึ่งคือสิ่งที่ผู้ใช้เห็นเมื่อการบันทึกถูกปฏิเสธเพราะมีคนแก้ไขเรคอร์ดแล้ว

UI ความขัดแย้งที่ดีมีสองเป้าหมาย: หยุดการเขียนทับเงียบ และช่วยให้ผู้ใช้ทำงานต่อให้เสร็จเร็วที่สุด หากทำดี มันรู้สึกเหมือนราวกันชนที่ช่วย ไม่ใช่อุปสรรค

รูปแบบ 1: กล่องโต้ตอบบล็อกง่าย ๆ (เร็วสุด)

ใช้เมื่อการแก้ไขสั้นและผู้ใช้สามารถนำการเปลี่ยนแปลงของตัวเองกลับมาใช้ได้หลังรีโหลด

ข้อความสั้นและเฉพาะเจาะจง: “เรคอร์ดนี้เปลี่ยนขณะคุณแก้ไข รีโหลดเพื่อดูเวอร์ชันล่าสุด” แล้วให้สองทางชัดเจน:

• รีโหลดและต่อ (ปุ่มหลัก)
• คัดลอกการแก้ไขของฉัน (ตัวเลือกที่ช่วยได้)

“คัดลอกการแก้ไขของฉัน” อาจคัดลอกค่าลงคลิปบอร์ดหรือเก็บค่าที่ยังไม่บันทึกไว้หลังรีโหลด เพื่อให้ผู้ใช้ไม่ต้องจดจำหรือพิมพ์ซ้ำ

วิธีนี้เหมาะกับอัปเดตฟิลด์เดี่ยว สวิตช์ สถานะ หรือหมายเหตุสั้น ๆ และง่ายที่สุดในการทำให้ทำงานได้บนตัวสร้าง UI อย่าง AppMaster

รูปแบบ 2: “ทบทวนการเปลี่ยนแปลง” (เหมาะกับเรคอร์ดมีมูลค่าสูง)

ใช้เมื่อเรคอร์ดสำคัญ (ราคา สิทธิ์จ่ายเงิน การตั้งค่าบัญชี) หรือฟอร์มยาว แทนที่จะส่งข้อผิดพลาดตายตัว ให้ผู้ใช้ไปยังหน้าจอความขัดแย้งที่เปรียบเทียบ:

• “การแก้ไขของคุณ” (สิ่งที่พวกเขาพยายามบันทึก)
• “ค่าปัจจุบัน” (ค่าล่าสุดจากฐานข้อมูล)
• “สิ่งที่เปลี่ยนไปตั้งแต่คุณเปิด” (ฟิลด์ที่ขัดกัน)

ให้แคบจุดสนใจ อย่าแสดงทุกฟิลด์ถ้ามีแค่สามฟิลด์ที่ขัดกัน

สำหรับแต่ละฟิลด์ที่ขัดกัน ให้ตัวเลือกง่าย ๆ:

• เก็บของฉัน
• ยอมรับของเขา
• รวม (เมื่อสมเหตุสมผล เช่น แท็กหรือหมายเหตุ)

หลังผู้ใช้แก้ไขความขัดแย้ง ให้บันทึกอีกครั้งด้วยค่าเวอร์ชันใหม่ หากรองรับ rich text หรือหมายเหตุยาว ให้แสดง diff เล็ก ๆ เพื่อให้ผู้ใช้ตัดสินใจเร็ว

เมื่ออนุญาตให้บังคับเขียนทับ (และใครทำได้)

บางครั้งต้องการบังคับเขียนทับ แต่ควรเป็นกรณีที่หาได้ยากและมีการควบคุม หากเพิ่ม ให้ทำให้การกระทำตั้งใจ: ขอเหตุผลสั้น ๆ บันทึกว่าใครทำ และจำกัดสิทธิ์ไว้เฉพาะบทบาทเช่น admin หรือ supervisor

สำหรับผู้ใช้ปกติ ให้ใช้ “ทบทวนการเปลี่ยนแปลง” เป็นค่าเริ่มต้น ตัวเลือกบังคับเขียนทับเหมาะเมื่อผู้ใช้เป็นเจ้าของเรคอร์ด ความเสี่ยงต่ำ หรือระบบกำลังแก้ข้อมูลผิดภายใต้การดูแล

สถานการณ์ตัวอย่าง: สองเพื่อนร่วมงานแก้ไขเรคอร์ดเดียวกัน

พนักงานสนับสนุนสองคน Maya และ Jordan ทำงานในเครื่องมือเดียวกัน ทั้งคู่เปิดโปรไฟล์ลูกค้าเดียวกันเพื่ออัปเดตสถานะและเพิ่มหมายเหตุหลังการโทรแยกกัน

ลำดับเหตุการณ์ (ด้วย optimistic locking ใช้ version หรือ updated_at):

• 10:02 - Maya เปิดลูกค้า #4821 ฟอร์มโหลด Status = "Needs follow-up", Notes = "Called yesterday" และ Version = 7
• 10:03 - Jordan เปิดลูกค้าคนเดียวกัน เขาเห็นข้อมูลเดียวกัน และ Version = 7
• 10:05 - Maya เปลี่ยน Status เป็น "Resolved" และเพิ่มหมายเหตุ "Issue fixed, confirmed by customer." แล้วคลิก Save
• 10:05 - เซิร์ฟเวอร์อัปเดตเรคอร์ด เพิ่ม Version เป็น 8 และเก็บบันทึก audit ว่าใครเปลี่ยนอะไรเมื่อไร
• 10:09 - Jordan พิมพ์หมายเหตุ "Customer asked for a receipt" แล้วคลิก Save

ถ้าไม่มีการตรวจสอบความขนาน การบันทึกของ Jordan อาจเขียนทับสถานะและหมายเหตุของ Maya ได้ ด้วย optimistic locking เซิร์ฟเวอร์จะปฏิเสธการอัปเดตของ Jordan เพราะเขากำลังพยายามบันทึกด้วย Version = 7 ในขณะที่เรคอร์ดอยู่ที่ Version = 8

Jordan จะเห็นข้อความความขัดแย้ง UI แสดงสิ่งที่เกิดขึ้นและให้ทางออกที่ปลอดภัย:

• รีโหลดเรคอร์ดล่าสุด (ทิ้งการแก้ไขของฉัน)
• นำการแก้ไขของฉันไปครอบบนเรคอร์ดล่าสุด (ถ้าเป็นไปได้)
• ทบทวนความแตกต่าง (แสดง "ของฉัน" เทียบกับ "ล่าสุด") แล้วเลือกเก็บอะไรบ้าง

หน้าจอเรียบง่ายอาจแสดง:

• “ลูกค้ารายนี้ถูกอัปเดตโดย Maya เวลา 10:05”
• ฟิลด์ที่เปลี่ยน (Status และ Notes)
• ตัวอย่างหมายเหตุที่ Jordan ยังไม่ได้บันทึก เพื่อให้เขาสามารถคัดลอกหรือนำไปใช้ใหม่ได้

Jordan เลือก “ทบทวนความแตกต่าง” เก็บสถานะของ Maya = "Resolved" แล้วต่อหมายเหตุของเขาไปที่หมายเหตุเดิม เขาบันทึกอีกครั้งด้วย Version = 8 ครั้งนี้สำเร็จ (ตอนนี้ Version = 9)

ผลสุดท้าย: ไม่สูญเสียข้อมูล ไม่มีการเดาว่าใครเขียนทับใคร และมี audit trail ชัดเจนที่แสดงถึงการเปลี่ยนสถานะของ Maya และหมายเหตุทั้งสองเป็นการแก้ไขแยกต่างหากที่สืบค้นได้ ในเครื่องมือที่สร้างด้วย AppMaster นี่สอดคล้องกับการตรวจสอบครั้งเดียวตอนอัปเดตบวกด้วยกล่องโต้ตอบเล็ก ๆ สำหรับจัดการความขัดแย้งใน UI

ความผิดพลาดที่พบบ่อยซึ่งยังคงทำให้ข้อมูลหาย

บั๊กส่วนใหญ่ของ “optimistic locking” ไม่ใช่แนวคิด แต่เกิดในจุดต่อส่งระหว่าง UI, API และฐานข้อมูล ถ้าชั้นใดชั้นหนึ่งลืมกฎไป คุณยังอาจเจอการเขียนทับเงียบ

ข้อผิดพลาดคลาสสิกคือเก็บเวอร์ชัน (หรือ timestamp) ตอนโหลดหน้าจอแก้ไข แต่ไม่ส่งกลับเมื่อต้องการบันทึก มักเกิดเมื่อฟอร์มถูกนำกลับมาใช้ใหม่ข้ามหน้าและฟิลด์ซ่อนหายไป หรือเมื่อไคลเอนต์ส่งเฉพาะฟิลด์ที่เปลี่ยน

กับกับดักอีกอย่างคือทำการตรวจสอบความขัดแย้งในเบราเซอร์เท่านั้น ผู้ใช้อาจเห็นคำเตือน แต่หากเซิร์ฟเวอร์รับอัปเดตไว้ไคลเอนต์อื่นหรือรีไทร์ก็ยังเขียนทับข้อมูลได้ เซิร์ฟเวอร์ต้องเป็นผู้ตัดสินสุดท้าย

รูปแบบที่ก่อให้เกิดการสูญเสียข้อมูลมากที่สุด:

• ขาดโทเคน concurrency ในคำขอบันทึก (version, updated_at หรือ ETag)
• ยอมรับการอัปเดตโดยไม่มีเงื่อนไขอะตอมิก เช่น อัปเดตโดย id อย่างเดียวแทน id + version
• ใช้ updated_at ที่มีความละเอียดต่ำ (เช่น วินาที) การแก้ไขสองครั้งในวินาทีเดียวอาจดูเหมือนเท่ากัน
• แทนที่ฟิลด์ใหญ่ (notes, descriptions) หรืออาร์เรย์ทั้งหมด (tags, line items) โดยไม่แสดงสิ่งที่เปลี่ยน ทำให้มีโอกาสลบการแก้ไขคนอื่น
• ถือว่าความขัดแย้งใด ๆ เป็น “แค่ลองใหม่” ซึ่งอาจนำค่าเก่ามาเขียนทับข้อมูลใหม่อีกครั้ง

ตัวอย่างชัดเจน: เจ้าหน้าที่สองคนเปิดเรคอร์ดลูกค้าคนเดียว คนหนึ่งเพิ่มหมายเหตุยาว อีกคนเปลี่ยนสถานะและบันทึก ถ้าการบันทึกของคุณแทนที่ payload ทั้งหมด การเปลี่ยนสถานะอาจลบหมายเหตุได้

เมื่อเกิดความขัดแย้ง ทีมยังสูญเสียข้อมูลถ้าการตอบกลับจาก API บางเกินไป อย่าแค่คืน “409 Conflict” ให้พอ ให้คืนข้อมูลพอให้มนุษย์แก้ปัญหาได้:

• เวอร์ชันปัจจุบันของเซิร์ฟเวอร์ (หรือ updated_at)
• ค่าล่าสุดของฟิลด์ที่เกี่ยวข้อง
• รายชื่อฟิลด์ที่ต่างกันอย่างชัดเจน
• ใครแก้ไขและเมื่อไร (ถ้าคุณติดตาม)

ถ้าคุณใช้ AppMaster ให้ยึดวินัยเดียวกัน: เก็บเวอร์ชันในสถานะ UI ส่งมันมากับการอัปเดต และบังคับการตรวจสอบในโลจิกแบ็กเอนด์ก่อนเขียนลง PostgreSQL

เช็คลิสต์ด่วนก่อนปล่อย

ก่อนปล่อย ให้ตรวจสอบความผิดพลาดที่ทำให้เกิดคำพูดว่า “มันบันทึกเรียบร้อย” ในขณะที่เงียบ ๆ เขียนทับงานคนอื่น

การตรวจสอบข้อมูลและ API

ตรวจสอบให้แน่ใจว่าเรคอร์ดมี token concurrency ครบจากต้นจนจบ โทเคนนี้อาจเป็น version หรือ updated_at แต่ต้องถือเป็นส่วนหนึ่งของเรคอร์ด ไม่ใช่เมตาดาต้าเลือกส่ง

• การอ่านรวม token (และ UI เก็บมันกับสถานะฟอร์ม ไม่ใช่แค่แสดงบนหน้าจอ)
• ทุกการอัปเดตส่ง token ที่เห็นล่าสุดกลับมา และเซิร์ฟเวอร์ตรวจสอบก่อนเขียน
• เมื่อสำเร็จ เซิร์ฟเวอร์คืน token ใหม่เพื่อให้ UI อยู่ในสถานะล่าสุด
• การแก้ไขแบบกลุ่มและการแก้ไขอินไลน์ต้องปฏิบัติเหมือนกัน ไม่มีทางลัดพิเศษ
• งานแบ็กกราวด์ที่แก้ไขแถวนั้นด้วยต้องตรวจสอบ token เช่นกัน (มิฉะนั้นมันจะสร้างความขัดแย้งที่ดูเหมือนไม่เป็นระบบ)

ถ้าคุณสร้างใน AppMaster ให้ตรวจสอบว่าฟิลด์ใน Data Designer มี (version หรือ updated_at) และ Business Process ของคุณเปรียบเทียบมันก่อนทำการอัปเดตจริง

การตรวจสอบ UI

ความขัดแย้งปลอดภัยก็ต่อเมื่อขั้นตอนถัดไปชัดเจน

เมื่อเซิร์ฟเวอร์ปฏิเสธการอัปเดต ให้แสดงข้อความชัดเจนว่า “เรคอร์ดนี้เปลี่ยนตั้งแต่คุณเปิดมัน” แล้วเสนอการกระทำปลอดภัยหนึ่งอย่างเป็นอย่างแรก: รีโหลดข้อมูลล่าสุด ถ้าเป็นไปได้ เพิ่มเส้นทาง “รีโหลดและนำการแก้ไขของฉันมาใช้ใหม่” ที่เก็บอินพุตยังไม่บันทึกและนำไปใช้กับเรคอร์ดที่รีเฟรช เพื่อการแก้ไขเล็ก ๆ ไม่ต้องพิมพ์ใหม่

ถ้าทีมคุณต้องการจริง ๆ ให้เพิ่มตัวเลือก “force save” ที่ควบคุมได้ จำกัดสิทธิ์ ยืนยัน และบันทึกผู้ที่บังคับบันทึกและสิ่งที่เปลี่ยน เพื่อให้เหตุฉุกเฉินเป็นไปได้โดยไม่ทำให้การสูญเสียข้อมูลเป็นค่าเริ่มต้น

ขั้นตอนถัดไป: เพิ่มล็อกให้ workflow เดียวแล้วขยาย

เริ่มจากจุดเล็ก ๆ เลือกหน้าจอแอดมินที่คนชนกันบ่อยแล้วเพิ่ม optimistic locking ที่นั่นก่อน พื้นที่ที่ชนสูงมักเป็นตั๋ว คำสั่งซื้อ ราคา และสต็อก ถ้าคุณทำให้ความขัดแย้งปลอดภัยบนหน้าจอที่คนใช้เยอะ หนึ่งหน้าจอจะสอนรูปแบบที่ทำซ้ำได้

กำหนดพฤติกรรมความขัดแย้งเริ่มต้นล่วงหน้า เพราะมันกำหนดทั้งโลจิกแบ็กเอนด์และ UI:

• บล็อกและรีโหลด: หยุดการบันทึก รีโหลดเรคอร์ดล่าสุด แล้วขอให้ผู้ใช้นำการแก้ไขมาทำซ้ำ
• ทบทวนและรวม: แสดง “การแก้ไขของคุณ” เทียบกับ “การแก้ไขล่าสุด” และให้ผู้ใช้ตัดสินใจ

Block-and-reload สร้างได้เร็วและเหมาะเมื่อการแก้ไขสั้น Review-and-merge คุ้มเมื่อเรคอร์ดยาวหรือมีความเสี่ยงสูง

แล้วทดสอบ flow หนึ่งให้ครบก่อนขยาย:

• เลือกหน้าจอหนึ่งและจดฟิลด์ที่ผู้ใช้แก้บ่อย
• เพิ่มค่า version (หรือ updated_at) ใน payload ฟอร์มและต้องการมันเมื่อบันทึก
• ทำให้การอัปเดตเป็นแบบมีเงื่อนไขในฐานข้อมูล (อัปเดตเฉพาะเมื่อเวอร์ชันตรงกัน)
• ออกแบบข้อความความขัดแย้งและการกระทำถัดไป (รีโหลด, คัดลอกข้อความของฉัน, เปิดหน้าจอเปรียบเทียบ)
• ทดสอบด้วยสองเบราว์เซอร์: บันทึกในแท็บ A แล้วพยายามบันทึกข้อมูลเก่าในแท็บ B

เพิ่มการบันทึกแบบน้ำหนักเบาสำหรับความขัดแย้ง เหตุการณ์ "เกิดความขัดแย้ง" พร้อมประเภทเรคอร์ด ชื่อหน้าจอ และบทบาทผู้ใช้ ช่วยให้คุณเห็นจุดที่ชนบ่อย

ถ้าคุณสร้างเครื่องมือแอดมินด้วย AppMaster (appmaster.io) ส่วนประกอบหลักจะจับคู่กันได้เรียบร้อย: กำหนดฟิลด์เวอร์ชันใน Data Designer บังคับการอัปเดตแบบมีเงื่อนไขใน Business Processes และเพิ่มกล่องโต้ตอบความขัดแย้งเล็ก ๆ ใน UI builder เมื่อ workflow แรกเสถียร ก็ทำซ้ำรูปแบบเดียวกันทีละหน้าจอ และรักษาความสม่ำเสมอของ UI ความขัดแย้งเพื่อให้ผู้ใช้เรียนรู้ครั้งเดียวแล้วไว้ใจได้ทั่วทั้งระบบ.