Thiết kế đồng thời cơ sở dữ liệu/webapp được ưu tiên khi nhiều người dùng có thể chỉnh sửa cùng một dữ liệu

Question

Tôi có một ASP.NET Web app kinh doanh được sử dụng trong nội bộ. Một vấn đề chúng tôi đang gặp phải khi chúng tôi phát triển là thiết kế ban đầu không tính đến việc kiểm tra đồng thời - vì vậy hiện tại nhiều người dùng đang truy cập vào cùng một dữ liệu và ghi đè những thay đổi khác của người dùng. Vì vậy, câu hỏi của tôi là - đối với webapps mọi người thường sử dụng một hệ thống đồng thời bi quan hoặc lạc quan? Điều gì thúc đẩy tùy chọn sử dụng cái khác hơn và một số cân nhắc thiết kế cần tính đến là gì?

Tôi hiện đang hướng tới một kiểm tra đồng thời lạc quan vì nó có vẻ khoan dung hơn, nhưng tôi lo ngại về khả năng xảy ra nhiều thay đổi sẽ có mâu thuẫn với nhau.

Cảm ơn!

Answer 1

Khóa lạc quan.
Tính bi quan khó thực hiện hơn và sẽ gây ra các vấn đề trong môi trường web. Hành động nào sẽ giải phóng khóa, đóng trình duyệt? Rời khỏi phiên để thời gian ra? Còn nếu họ lưu các thay đổi của họ thì sao?

Bạn không chỉ định cơ sở dữ liệu nào bạn đang sử dụng. Máy chủ MS SQL có kiểu dữ liệu dấu thời gian. Nó không có gì để làm với thời gian mặc dù. Nó là mearly một số sẽ được thay đổi mỗi khi hàng được cập nhật. Bạn không phải làm bất cứ điều gì để đảm bảo nó được thay đổi, bạn chỉ cần kiểm tra nó. Bạn có thể đạt được tương tự bằng cách sử dụng ngày/giờ được sửa đổi lần cuối vì @KM đề xuất. Nhưng điều này có nghĩa là bạn phải nhớ thay đổi nó mỗi khi bạn cập nhật hàng. Nếu bạn sử dụng datetime, bạn cần sử dụng kiểu dữ liệu với độ chính xác đủ để đảm bảo rằng bạn không thể kết thúc với giá trị không thay đổi khi cần. Ví dụ, một số tiết kiệm một hàng, sau đó ai đó đọc nó, sau đó lưu khác xảy ra nhưng để lại ngày/thời gian sửa đổi không thay đổi. Tôi sẽ sử dụng dấu thời gian trừ khi có yêu cầu theo dõi ngày sửa đổi cuối cùng trên hồ sơ.

Để kiểm tra xem bạn có thể làm như @KM đề xuất và đưa nó vào câu lệnh cập nhật ở đâu. Hoặc bạn có thể bắt đầu một giao dịch, kiểm tra dấu thời gian, nếu tất cả là tốt làm việc cập nhật, sau đó cam kết giao dịch, nếu không thì trả về một mã lỗi hoặc lỗi.

Mở giao dịch mở (theo đề xuất của @le dorfier) ​​tương tự như khóa bi quan, nhưng lượng dữ liệu bị khóa có thể nhiều hơn một hàng. Hầu hết khóa của RDBM ở cấp trang theo mặc định.Bạn cũng sẽ chạy vào các vấn đề tương tự như với khóa bi quan.

Bạn đề cập đến trong câu hỏi của mình rằng bạn đang lo lắng về các cập nhật xung đột. Đó là những gì khóa sẽ ngăn chặn chắc chắn. Cả hai lạc quan hoặc bi quan sẽ, khi thực hiện đúng cách ngăn chặn chính xác điều đó.

Answer 2

Tôi cho rằng bạn đang gặp sự cố 'cập nhật bị mất'.

Để chống lại điều này như một quy tắc, tôi sử dụng khóa bi quan khi cơ hội va chạm cao (hoặc giao dịch ngắn ngủi) và khóa lạc quan khi cơ hội va chạm thấp (hoặc giao dịch lâu, hoặc quy tắc kinh doanh của bạn bao gồm nhiều giao dịch).

Bạn thực sự cần xem điều gì áp dụng cho trường hợp của bạn và thực hiện cuộc gọi phán đoán.

Answer 3

đây là giải pháp đơn giản cho nhiều người làm việc trên cùng một hồ sơ.

khi bạn tải các dữ liệu, có ngày thay đổi cuối cùng, chúng tôi sử dụng LastChgDate trên bảng của chúng tôi

khi bạn lưu (cập nhật) các dữ liệu thêm "VÀ LastChgDate = previouslyLoadedLastChgDate" vào mệnh đề where. Nếu hàng đếm = 0 trên bản cập nhật, phát hành lỗi khi "ai đó khác đã lưu dữ liệu này" và khôi phục mọi thứ, nếu không thì dữ liệu sẽ được lưu.

Tôi thường chỉ làm logic trên trên các bảng tiêu đề chứ không phải trên các bảng chi tiết, vì chúng là tất cả trong một giao dịch.

Answer 4

Tôi đồng ý với câu trả lời đầu tiên ở trên, chúng tôi cố gắng sử dụng khóa lạc quan khi cơ hội va chạm khá thấp. Điều này có thể dễ dàng được triển khai với cột LastModifiedDate hoặc tăng cột Phiên bản. Nếu bạn không chắc chắn về tần suất va chạm, đăng nhập xảy ra ở đâu đó để bạn có thể theo dõi chúng. Nếu hồ sơ của bạn luôn ở chế độ "chỉnh sửa", có chế độ "chế độ xem" và "chỉnh sửa" riêng biệt có thể giúp giảm va chạm (giả sử bạn tải lại dữ liệu khi vào chế độ chỉnh sửa).

Nếu va chạm vẫn còn cao, việc bi quan khó thực hiện hơn trong các ứng dụng web, nhưng chắc chắn có thể. Chúng tôi đã có thành công tốt với hồ sơ "cho thuê" (khóa với thời gian chờ) ... tương tự như cảnh báo 2 phút bạn nhận được khi bạn mua vé trên TicketMaster. Khi người dùng chuyển sang chế độ chỉnh sửa, chúng tôi sẽ lưu bản ghi vào bảng "khóa" với thời gian chờ là N phút. Những người dùng khác sẽ thấy thông báo nếu họ cố chỉnh sửa bản ghi bằng khóa đang hoạt động. Bạn cũng có thể triển khai một biểu mẫu lưu giữ lâu dài bằng cách gia hạn hợp đồng thuê trên bất kỳ trang đăng lại nào của trang hoặc thậm chí với bộ hẹn giờ ajax. Cũng không có lý do tại sao bạn không thể quay lại điều này với một khóa tiêu chuẩn lạc quan đã đề cập ở trên.

Nhiều ứng dụng sẽ cần kết hợp cả hai cách tiếp cận.