Làm thế nào để bạn xử lý nhiều người dùng chỉnh sửa cùng một dữ liệu trong một ứng dụng web?


26

Có một dự án tôi đang làm việc đang tìm cách sản xuất một ứng dụng web sẽ quản lý danh sách nhiệm vụ giữa nhiều người dùng. Đây là danh sách tác vụ chính có các mục nhiệm vụ được phân phối bởi người dùng được ủy quyền. Mỗi người dùng có tài khoản riêng của mình để đăng nhập và xem các nhiệm vụ họ được giao; nhiều người dùng có thể có một nhiệm vụ chung.

Tôi đang cố gắng loại bỏ các chi tiết của dự án vì tôi đang vật lộn nhiều hơn với khái niệm chung về cách xử lý các tình huống sau, nhưng nếu nó giúp, tôi đang sử dụng Java, EclipseLink và GWT với RequestFactory được triển khai. Cơ sở dữ liệu là PostgreSQL.

Vì vậy, các vấn đề khái niệm tôi đang cố gắng hòa giải là như sau:

  1. Nếu một tác vụ chung cho nhiều người dùng thay đổi theo bất kỳ cách nào, ví dụ như tác vụ đã hoàn thành, đã xóa, v.v., danh sách nhiệm vụ của tất cả người dùng có tác vụ này sẽ được cập nhật. Những mẫu thiết kế nào có hỗ trợ thực hiện chức năng này?

    • Một số mẫu tôi đã xem là Người quan sát và Người hòa giải - có những mẫu nào khác cần được xem xét về những mẫu này không?
  2. Nói rằng có hai người dùng thay đổi cùng một nhiệm vụ cùng một lúc.

    • Đầu tiên, tôi nên cho phép tình huống đó xảy ra hay tôi nên khóa nó cho đến khi một hoặc người khác thực hiện thay đổi?

    • Thứ hai, nếu tôi không cài khóa, làm cách nào để điều chỉnh những thay đổi được chấp nhận? Điều này liên quan đến tình huống trong 1 vì người dùng 1 có thể gửi dữ liệu và trước khi người dùng 2 nhận được dữ liệu cập nhật, anh ấy / cô ấy có thể đã đi trước và gửi các thay đổi của mình.

Tôi thực sự đang tìm kiếm bất kỳ điểm hướng dẫn, lời khuyên hoặc mẹo nào bạn có thể cung cấp về cách đồng bộ hóa dữ liệu đúng cách giữa nhiều phiên bản của ứng dụng web này. Tôi rất đánh giá cao điều đó!

Câu trả lời:


17

Tôi nghĩ Whiteboard sẽ là mô hình lựa chọn của bạn cho # 1, bạn nên đăng các thay đổi cho các nhiệm vụ (hoặc dữ liệu chia sẻ khác) ở một nơi chung, vì vậy tất cả các bên quan tâm có thể thấy chúng và DTRT.

Đối với # 2, bạn cần xem xét khóa lạc quan . Về cơ bản, bạn cần đánh dấu thời gian tất cả các bản ghi có thể chỉnh sửa của bạn với thời gian cập nhật mới nhất. Khi bạn cố lưu bản ghi, trước tiên bạn xác minh rằng bản ghi trong cơ sở dữ liệu có dấu thời gian được cập nhật lần cuối giống như bản ghi của bạn. Nếu không, thì ai đó đã cập nhật bản ghi và bây giờ bạn phải lấy bản ghi đã cập nhật và thông báo cho người dùng rằng họ cần nhập lại các thay đổi của họ hoặc bạn có thể thử hợp nhất các thay đổi của người dùng vào bản ghi được cập nhật (thường là đơn giản hoặc không thể).


7

Tôi đã đưa ra một thiết kế cho một ứng dụng máy tính để bàn (chưa được thử nghiệm đầy đủ) với các yêu cầu tương tự có thể hữu ích.

Giải pháp của tôi là sử dụng mẫu MVC (với một Model duy nhất nhưng nhiều Bộ điều khiển và Chế độ xem) trong đó mỗi Bộ điều khiển thực hiện thay đổi cho Model bằng các giao dịch (sử dụng STM ) và khi giao dịch được cam kết, Model sẽ phát thông báo cập nhật cho Chế độ xem ).

Mỗi khách hàng cũng theo dõi mọi thứ đang được cập nhật cục bộ, nhưng khi những cập nhật cục bộ đó kết thúc (nghĩa là được gửi để được cam kết), nó sẽ trở lại sử dụng thông tin của Mô hình cơ bản.

Tôi cũng đã có một ngăn xếp hoàn tác với tất cả các thay đổi mà người dùng đã thực hiện để mọi thứ có thể được hoàn nguyên.

Đây có thể không phải là mô hình tốt nhất cho ứng dụng web mặc dù Mô hình phải phát các thay đổi cho Chế độ xem, có thể không phải là ứng dụng khách dễ dàng nhất với web.


4

cho 1. bạn nên xem mẫu xuất bản / đăng ký có phù hợp hơn không.
cho 2. nó phụ thuộc vào tình huống của bạn:

  • tình trạng này sẽ xảy ra thường xuyên như thế nào?
  • Làm thế nào xấu là một tình huống trong đó một trong những người dùng của bạn sẽ không thể cập nhật một tác vụ vì nó bị khóa hoặc người khác đã thay đổi nó trong lúc này?
    cá nhân tôi thích một cách tiếp cận (được sử dụng trong pivotaltracker ) trong đó có:
    • không có ổ khóa,
    • bạn thấy tất cả các thay đổi trong thời gian thực và
    • UI mời thực hiện các cập nhật nhỏ thường xuyên thay vì các cập nhật lớn hơn trên nhiều thuộc tính.
    • bạn giữ một lịch sử của tất cả các thay đổi đã được thực hiện. nếu lịch sử hiển thị cho người dùng, cuối cùng phát sinh xung đột hoặc ghi đè có thể được giải quyết bằng các bình luận, chú thích hoặc tin nhắn.

Câu hỏi mang tính học thuật hơn, vì vậy tôi sẽ nói rất thường xuyên để xem xét nó được chăm sóc như thế nào trong trường hợp xấu nhất. +1 cho các tham chiếu mẫu.
hulkmeister

@ kr1 pivotaltracker thiếu cảnh báo xung đột và không hợp nhất các thay đổi không xung đột, vì vậy không nên sử dụng một ví dụ điển hình của ứng dụng nhiều người chỉnh sửa hồ sơ tốt.
Eduardo

0
  • Khóa hồ sơ. Điều này không được ưa thích vì nó sẽ làm giảm sự tương tranh và hồ sơ có thể bị khóa trong thời gian nhiều hơn mức cần thiết.
  • Cuối cùng để gửi ghi đè thay đổi đồng thời khác. Người dùng không muốn điều này. Một số phần mềm như JIRA làm điều này. https://community.atlassian.com/t5/Jira-questions/Edit-a-JIRA-Issue-at-the-same-time-by-two-Users-result-in-last/qaq-p/389243
  • Chỉnh sửa đồng thời. Ứng dụng chỉ nên gửi các trường của hồ sơ được thay đổi. Bằng cách đó bạn ngăn ngừa xung đột. Hầu hết các phần mềm wiki có thể hợp nhất các thay đổi vào cùng một trường văn bản nếu không có xung đột: /programming//questions 43211888 / how-does-a-wiki-handle-multipl-fax-edits Xem ví dụ MediaWiki như nó cho phép chỉnh sửa đồng thời và có giao diện người dùng tốt trong trường hợp có xung đột: https://www.mediawiki.org/wiki/Extension:TwoColConflict

Đề nghị của tôi là không bao giờ khóa và báo cáo một cuộc xung đột nếu nó xảy ra.

Xin vui lòng, hãy xem:

https://github.com/spring-projects/spring-petclinic/issues/433

Bạn có thể xem một video và mã mẫu.

Điều đó sẽ đáp ứng yêu cầu của bạn?

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.