2009-09-07 35 views
5

Tôi đang tạo một ứng dụng web có một vài màn hình quản lý, nơi người dùng có thể chỉnh sửa bản ghi (ví dụ, thay đổi chi tiết liên lạc của người dùng). Truy cập vào các màn hình quản lý này được điều khiển bởi các vai trò, với nhiều người dùng có thể có quyền truy cập. Vấn đề bây giờ là phải làm gì nếu hai người dùng đồng thời cố gắng chỉnh sửa cùng một bản ghi.Thiết kế web front-end cho sửa đổi đồng thời

Sự cố của tôi là với giao diện người dùng, không phải với giao diện người dùng. Một số mẫu mà tôi có thể sử dụng để thiết kế các trang của mình để vừa thân thiện với người dùng vừa ngăn không cho sửa đổi đồng thời là gì? Hai lựa chọn duy nhất tôi có thể nghĩ đến là:

  • Khóa bi quan: Khó khăn trong môi trường web, nơi tôi có thể chờ phiên để hết giờ trước khi có thể giải phóng khóa trong hầu hết các trường hợp.
  • Khóa lạc quan: Không tốt về mặt thân thiện với người dùng, vì người dùng có thể điền vào biểu mẫu lớn chỉ để được chào đón bằng thông báo "không thể lưu" ở cuối.

Mọi đề xuất?

+0

Khóa lạc quan không liên quan đến việc thân thiện với người dùng hoặc cách khác; nó xuống để thực hiện. Câu hỏi lớn là tần suất dự kiến ​​của các chỉnh sửa đồng thời trên cùng một bản ghi là bao nhiêu? Nếu thấp, khóa lạc quan đơn giản thắng. – SteveD

Trả lời

2

Làm thế nào về đặt trước theo thời gian? Đây là một mô hình được sử dụng trong nhiều hệ thống đặt phòng trực tuyến.

Ví dụ dựa trên trường hợp bảng đơn nhỏ (Tôi hy vọng rằng việc mở rộng sang nhiều bảng hơn phải rõ ràng) Thêm cột vào bảng có tên RESERVATION_TIME. Tất cả các hồ sơ ban đầu được phổ biến với thời gian đặt trước của "nhiều năm trước".

Sử dụng kết hợp này với khóa lạc quan. Tại thời điểm bạn đi vào chế độ Edit bạn

  • Để đặt phòng cho các hồ sơ một bạn muốn

    CẬP NHẬT RESERVATION_TIME để VỚI DOANH NGHIỆP nơi KEY = id và RESERVATION_TIME hơn 30 mins ago

Điều này sẽ chỉ hoạt động nếu không có ai đã thiết lập cập nhật cho gần đây. Ý tưởng là chúng tôi thậm chí không cho phép màn hình chỉnh sửa được điền nếu một số người dùng khác đã hoạt động. Nhưng chúng tôi đặt đặt chỗ đó hết hạn sau 30 phút (hoặc bất kỳ thứ gì) để không có gì bị "khóa" một cách vĩnh viễn. Nhưng lưu ý rằng chúng tôi không (trong điều khoản cơ sở dữ liệu) đang nắm giữ một khóa bi quan.

  • Bây giờ lấy dữ liệu (có thể trọ cùng tran như đã đặt phòng)

  • trên ghi lại kiểm tra vị lạc quan và rõ ràng trong hồ sơ đặt trở lại một thời gian dài trước đây.

Bây giờ điều này trung gian giữa hai người dùng của bất kỳ ứng dụng nào tôn trọng hệ thống đặt trước. Khóa lạc quan trung gian giữa tất cả người dùng lạc quan của hệ thống, do đó người dùng vẫn có thể bị kích thích, nhưng giả sử rằng các bản cập nhật ngoài băng là rất hiếm thì bạn sẽ nhận được khả năng sử dụng được chấp nhận.

Một số ý tưởng khác:

  1. cuối tiết kiệm thắng - đối với một số dữ liệu không có điểm nào trong khóa. Bạn sẽ cho phép người dùng Bill thay đổi công việc của Alice và ngược lại, vì vậy cho phép hoặc là giành chiến thắng.
  2. Phát hiện xung đột và hợp nhất. Giống như hệ thống kiểm soát nguồn CVS. Sử dụng một lược đồ lạc quan và trong trường hợp xung đột thể hiện cập nhật can thiệp và cập nhật được đề xuất và yêu cầu người dùng giải quyết xung đột.
+0

Cảm ơn bạn đã gợi ý, nhưng bạn có thể vui lòng xây dựng trên đề xuất đặt chỗ của mình không.Tôi không hoàn toàn làm theo - bạn có nghĩa là tôi nên sử dụng một khóa bi quan như đặt phòng, nhưng cũng cho phép khóa lạc quan nếu bạn không có khóa độc quyền? – Zecrates

+0

Trả lời cập nhật một chút – djna

1

Chúng tôi thực hiện một cơ chế đầu tiên-ghi-thắng trong những tình huống tương tự (hoặc khóa lạc quan)

backend:

Tạo một lĩnh vực dấu thời gian trong cơ sở dữ liệu (điều này được tự động cập nhật trong MSSQL trên INSERT and UPDATE)

Khi bạn tải các đối tượng để chỉnh sửa, bao gồm thuộc tính dấu thời gian, chỉ cho phép lưu trong các thủ tục đã lưu của bạn nếu dấu thời gian giống nhau ném một lỗi, xử lý điều này trong ứng dụng của bạn cho biết hồ sơ đã thay đổi và cung cấp cho họ cơ hội tải lại trang. Điều này hoạt động tốt trên web/môi trường bị ngắt kết nối.

Front End

Trang cần phải thăm dò ý kiến ​​các cơ sở dữ liệu (sử dụng ajax) để phát hiện một sự thay đổi. Nếu có lời nhắc thay đổi, người dùng cho biết bản ghi đã thay đổi và tùy chọn tải lại/hợp nhất. Trên nhãn hiển thị của trang postback hoặc các trường biểu mẫu thứ cấp (chỉ đọc) với các giá trị được nhập mới ở bên phải có thể được sao chép, ví dụ như nút mũi tên trỏ sang trái sao chép các giá trị trở lại các trường biểu mẫu ban đầu.

+0

Đó là khóa lạc quan phải không? Và tải lại là vấn đề người hỏi có - sâu sắc thân thiện nếu người dùng chỉ cần dành 10 phút điền vào rất nhiều thông tin chi tiết vào giao diện người dùng. "QUÁ TẤT CẢ CHÚNG TA ĐÃ CHẶN GOT ONE! Hãy gõ lại tất cả." – djna

+0

"Khóa lạc quan" và điểm tốt :-) cảm ơn. Đã cập nhật câu trả lời. –

0

Tôi đồng ý với bạn rằng Khóa lạc quan không thân thiện với người dùng.

Đối với khóa bi quan, tôi nghĩ bạn có thể vượt qua các vấn đề:

  • Để phát hành các khóa thường xuyên hơn, bạn có thể sử dụng một delai để khóa, trong cơ sở dữ liệu của bạn. Sau khi xóa hết hạn, người dùng khác có thể phá khóa. Người dùng đầu tiên sẽ được thông báo về nó. Điều đó cần phải rõ ràng ngay từ đầu.

  • Bạn cũng có thể sử dụng tính năng tự động làm mới lặp lại trong trang khóa. Tại mỗi yêu cầu (ajax), bạn ghi nhớ thời gian. Do đó, nếu trên máy chủ, một khóa cũ hơn tốc độ làm mới, điều đó có nghĩa là người dùng không còn ở trên trang này nữa. Vì vậy, mặc dù phiên không hết hạn, bạn có thể làm sạch khóa.

0

Bạn có thể làm cho người dùng Khóa lạc thân thiện bằng cách truy xuất hồ sơ đã sửa đổi và hiển thị so sánh với dữ liệu họ đã gửi.

Bạn có thể thực hiện thêm một bước nữa và triển khai giao diện giống như TortoiseSVN để chỉnh sửa xung đột (nếu có).

Điều này có thể yêu cầu một chút nỗ lực giao diện người dùng, nhưng điều này sẽ dẫn đến một cách hay để cho phép chỉnh sửa đồng thời.

Bạn có thể muốn kiểm tra mã HTML/JS/CSS được sử dụng trong Rietveld làm ví dụ về cách tạo nice diff interface.

Các vấn đề liên quan