Database hay gặpOptimistic locking không giữ khoá nào cả.
Bạn đọc dữ liệu kèm số version, khi ghi thì đưa version cũ vào WHERE; nếu ai đó đã sửa trước, câu lệnh cập nhật 0 hàng và bạn biết là có xung đột.
-- read
SELECT id, price, version FROM products WHERE id = 7; -- version = 3
-- write
UPDATE products
SET price = 120, version = version + 1
WHERE id = 7 AND version = 3;
-- rowCount = 0 → có người sửa trước, phải đọc lại và xử lý xung độtTầng ứng dụng bắt buộc phải kiểm tra số hàng bị ảnh hưởng. Bỏ qua bước này thì cơ chế mất tác dụng hoàn toàn — đây là lỗi hay gặp nhất. ORM như Hibernate/JPA (@Version) hay EF Core (IsConcurrencyToken) làm sẵn phần kiểm tra và ném OptimisticLockException.
Chọn optimistic khi: xung đột hiếm, người dùng chỉnh sửa form dài (không thể giữ khoá suốt thời gian đó), hoặc muốn tránh mọi rủi ro khoá kéo dài.
Chọn pessimistic khi: tranh chấp cao trên cùng vài hàng (trừ tồn kho flash sale, ví tiền). Lúc đó optimistic sẽ khiến phần lớn request thất bại rồi retry liên tục, tổng chi phí cao hơn là xếp hàng chờ khoá.