Bỏ qua điều hướng
Blog

Hai người cùng sửa một bản ghi: dùng phiên bản để tránh ghi đè

Kiểm soát hai người cùng sửa bản ghi bằng ETag và If-Match; thiết kế thông báo xung đột, so sánh thay đổi và ca nghiệm thu không mất dữ liệu.

Chia sẻFacebookLinkedInZalo
Hai người cùng sửa một bản ghi: dùng phiên bản để tránh ghi đè
Nội dung bài viết

Thông báo lưu thành công có thể che một lần ghi đè. Khi hai người mở cùng bản ghi, hệ thống cần biết người lưu sau đang sửa phiên bản nào và xử lý khác biệt trước khi chấp nhận.

Vì sao khóa nút lưu chưa đủ

Khóa nút trong một trình duyệt chỉ ngăn thao tác lặp tại đó. Nó không kiểm soát người khác, ứng dụng di động hay một job tích hợp đang cập nhật cùng dữ liệu. Bài toán là nhận diện phiên bản được mở, không chỉ nhận diện tài khoản thao tác.

Hợp đồng cập nhật có điều kiện

Khi đọc bản ghi, ứng dụng giữ ETag hoặc một trường phiên bản do máy chủ cấp. Khi lưu, gửi điều kiện tương ứng; endpoint phải kiểm tra điều kiện ngay trong đường ghi dữ liệu. Nếu API không hỗ trợ If-Match, nhóm phát triển cần cơ chế phiên bản tương đương, không giả định thêm header ở giao diện là đủ.

tránh ghi đè dữ liệu khi cùng sửa: Đọc bản hiện hành, Giữ mã phiên bản, Gửi điều kiện lưu, So sánh xung đột, Duyệt bản hợp nhất
Quy trình đề xuất để nghiệm thu; điều kiện cụ thể cần xác nhận theo hệ thống đang dùng.

Ví dụ giả định: hai người cập nhật địa chỉ giao hàng

Nhân viên A sửa số điện thoại, nhân viên B sửa địa chỉ từ cùng phiên bản ban đầu. Nếu B gửi lại toàn bộ biểu mẫu cũ, số điện thoại của A có thể bị mất. Khi phát hiện xung đột, giữ phần B đã nhập và hiển thị bản máy chủ mới để người phụ trách quyết định từng trường. Không tự lấy bản lưu sau làm đúng.

Tình huống Phản ứng mong muốn Bằng chứng
Phiên bản còn hiện hành Cho lưu có điều kiện Phiên bản mới
Phiên bản đã đổi Giữ bản nháp, báo xung đột Không mất thay đổi trước
Mất quyền khi lưu Từ chối theo quyền hiện tại Không lộ nội dung mới

Thiết kế màn hình giải quyết khác biệt

Thông báo cần nói bản ghi đã đổi, trường nào khác và thao tác tiếp theo. Không xóa nội dung người dùng đang nhập khi nhận lỗi. Với dữ liệu có ràng buộc liên trường, như địa chỉ và vùng giao hàng, không hợp nhất riêng từng trường nếu chưa kiểm tra lại quy tắc nghiệp vụ.

Ca nghiệm thu phải có hai phiên thật

Mở cùng bản ghi ở hai phiên thử nghiệm; cho phiên A lưu trước, phiên B lưu sau. Kiểm tra B được cảnh báo và A không bị ghi đè âm thầm. Thử tiếp bản ghi đã bị xóa, người dùng mất quyền giữa lúc sửa và phiên bản cũ được gửi lại. Mỗi tình huống cần trạng thái rõ thay vì thông báo lỗi chung.

Khi nào nên chọn khóa bi quan

Một số công việc cần giữ quyền xử lý độc quyền trong thời gian ngắn. Khi đó phải có thời hạn khóa và cách giải phóng khi phiên bị ngắt. Không áp dụng khóa dài cho mọi biểu mẫu; chọn theo mức độ thiệt hại và khả năng hợp nhất, thay vì chọn theo thói quen lập trình.

Chuẩn bị gì khi trao đổi phạm vi triển khai?

Mang theo một ca hai người cùng sửa và các trường không được mất khi trao đổi phạm vi phần mềm quản lý. Cách giải quyết xung đột cần được owner nghiệp vụ duyệt trước khi lựa chọn khóa hay phiên bản.

Nguồn kiểm chứng và giới hạn áp dụng

Tài liệu chính thức: If-Match hỗ trợ điều kiện cập nhật theo ETag. Đối chiếu ngày 12/10/2026. Các bảng và quy trình trong bài là đề xuất biên tập; ví dụ giả định không phải dự án hay kết quả khách hàng Onter.

Tài khoản Onter

Đăng nhập rồi tiếp tục việc đang làm.

Mở trang đăng nhập riêng nếu trình duyệt chưa hiển thị biểu mẫu.

Contact Me on Zalo