webappで同じデータを編集している複数のユーザーをどのように処理しますか？

私が取り組んでいるプロジェクトは、複数のユーザー間でタスクリストを管理するWebアプリケーションを作成することです。これは、承認されたユーザーによってタスクアイテムが配布されるマスタータスクリストです。各ユーザーは、割り当てられたタスクにログインして表示するための独自のアカウントを持っています。複数のユーザーが単一のタスクを共有することは可能です。

次の状況を処理する方法の全体的な概念にさらに取り組んでいるので、プロジェクトの詳細をここから省こうとしていますが、それが役立つ場合は、RequestFactoryを実装したJava、EclipseLink、GWTを使用しています。データベースはPostgreSQLです。

したがって、私が調整しようとしている概念的な問題は次のとおりです。

1. 複数のユーザーに共通の単一のタスクが何らかの方法で変更された場合（タスクの完了、削除など）、このタスクを持つすべてのユーザーのタスクリストが更新されます。この機能の実装を支援する設計パターンはありますか？

   • 私が調べたパターンには、ObserverとMediatorがあります。これらについて検討すべき他のパターンはありますか？

2. 2人のユーザーが同じタスクを同時に変更しているとします。

   • まず、そのような状況が発生するのを許可する必要がありますか、それとも誰かが変更を行うまでロックする必要がありますか？

   • 次に、ロックをかけない場合、どの変更を受け入れるかを調整するにはどうすればよいですか？これには、ユーザー1がデータを送信でき、ユーザー2が更新されたデータを受信する前に、先に進んで変更を送信した可能性があるため、1の状況が含まれます。

このWebアプリの複数のインスタンス間でデータを適切に同期する方法について提供できるガイドポイント、アドバイス、またはヒントを本当に探しています。とても感謝しています！

ホワイトボードは、＃1の選択パターンになると思います。タスク（または他の共有データ）の変更を共通の場所に投稿して、すべての関係者がそれらとDTRTを見ることができるようにします。

＃2については、楽観的ロックを確認する必要があります。基本的に、すべての編集可能なレコードに最終更新時刻のタイムスタンプを付ける必要があります。レコードを保存しようとするとき、最初にデータベース内のレコードがレコードと同じ最終更新タイムスタンプを持っていることを確認します。そうでない場合、誰かがレコードを更新したため、更新されたレコードを取得して、ユーザーに変更を再度入力する必要があることをユーザーに通知するか、ユーザーの変更を更新されたレコードにマージすることができます（通常は判明します）単純または不可能になります）。

役に立つかもしれない同様の要件を持つデスクトップアプリケーション（まだ完全にはテストされていない）の設計を思いつきました。

私の解決策は、MVCパターン（単一のモデルで複数のコントローラーとビュー）を採用することで、各コントローラーがトランザクションを使用して（STMを使用して）モデルに変更を加え、トランザクションがコミットされると、モデルが更新通知をビューにブロードキャストしました）。

各クライアントはすべて、ローカルで更新されるものをすべて追跡していましたが、それらのローカル更新が完了すると（つまり、コミットするために送信されると）、基になるモデルの情報を使用するようになりました。

また、ユーザーが行ったすべての変更を元に戻すことができるように、取り消しスタックがありました。

ただし、モデルはビューへの変更をブロードキャストする必要があるため、これはWebアプリの最適なモデルではない可能性があります。ビューはWebクライアントでは最も簡単ではない場合があります。

1.の場合、パブリッシュ/サブスクライブパターンがより適しているかどうかを確認する必要があります。
2.状況によって異なります。

• この状況はどのくらいの頻度ですか？
• ユーザーの1人がタスクがロックされているか、他の誰かがその間にタスクを変更したためにタスクを更新できない状況はどれほど悪いですか？
  個人的には、次のようなアプローチが必要です（たとえば、pivotaltrackerで使用）。
  • ロックなし、
  • すべての変更がリアルタイムで表示されます。
  • UIは、複数の属性に対して大きな更新を行う代わりに、頻繁にマイナー更新を行うことを勧めます。
  • 行われたすべての変更の履歴を保持します。履歴がユーザーに表示される場合、最終的に発生する競合または上書きは、コメント、注釈、またはメッセージで解決できます。

• レコードをロックします。同時実行性が低下し、必要以上の時間レコードがロックされる可能性があるため、これは好ましくありません。
• 最後に送信すると、他の同時変更が上書きされます。ユーザーはこれを望んでいません。JIRAのような一部のソフトウェアはこれを行います。https://community.atlassian.com/t5/Jira-questions/Edit-a-JIRA-Issue-at-the-same-time-by-two-Users-result-in-last/qaq-p/389243
• 同時編集。アプリケーションは、変更されたレコードのフィールドのみを送信する必要があります。そうすれば、競合を防ぐことができます。競合がない場合、ほとんどのウィキソフトウェアは同じテキストフィールドへの変更をマージできます。https : //stackoverflow.com/questions/3411888/how-does-a-wiki-handle-multiple-simultaneous-edits たとえばMediaWikiを参照してください同時編集を許可し、競合の場合に優れたUIを備えています：https : //www.mediawiki.org/wiki/Extension : TwoColConflict

競合が発生した場合は、ロックして競合を報告しないことをお勧めします。

ご覧ください：

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

ビデオとサンプルコードを見ることができます。

それは要件を満たしますか？