Optimistic Locking là một chiến lược trong đó bạn đọc bản ghi, ghi lại version number (các phương pháp khác để thực hiện việc này liên quan đến dates, timestamps hoặc checksums / hashes) và kiểm tra xem phiên bản này (version) có thay đổi không trước khi bạn ghi lại bản ghi (record). Khi bạn ghi lại bản ghi, bạn lọc bản cập nhật trên phiên bản này để đảm bảo rằng nó là nguyên tử (atomic). (tức là chưa được cập nhật trong giữa khoảng thời gian khi bạn kiểm tra phiên bản và ghi bản ghi vào đĩa) và cập nhật phiên bản trong một lần truy cập.

Nếu bản ghi bị thay đổi (tức là phiên bản khác với phiên bản của bạn), bạn hủy giao dịch và người dùng có thể bắt đầu lại.

Chiến lược này được áp dụng nhiều nhất cho các hệ thống khối lượng lớn và kiến ​​trúc ba tầng, nơi bạn không nhất thiết phải duy trì kết nối với cơ sở dữ liệu cho phiên của mình. Trong trường hợp này, máy khách thực sự không thể duy trì các khóa cơ sở dữ liệu vì các connections được lấy từ một pool và bạn có thể không sử dụng cùng một connection từ lần truy cập này đến lần truy cập tiếp theo.

Pessimistic Locking là khi bạn khóa bản ghi cho mục đích sử dụng riêng của mình cho đến khi bạn hoàn thành nó. Nó có tính toàn vẹn tốt hơn nhiều so với Optimistic Locking nhưng đòi hỏi bạn phải cẩn thận với thiết kế ứng dụng của mình để tránh Deadlocks. Để sử dụng Pessimistic Locking, bạn cần có một connection trực tiếp đến cơ sở dữ liệu (như trường hợp thường xảy ra trong ứng dụng hai tầng client-server) hoặc ID transaction có sẵn bên ngoài có thể được sử dụng độc lập với connection.

Nhược điểm của Pessimistic Locking là một resource sẽ bị khóa từ thời điểm nó được truy cập lần đầu trong một giao dịch cho đến khi giao dịch kết thúc, khiến nó không thể truy cập được vào các giao dịch khác trong thời gian đó.