ドキュメントサーバー：同時保存の処理

Question

私はドキュメントサーバーを実装しています。現在、2人のユーザーが同じ文書を開き、変更して変更を保存すると、文書の状態は未定義になります（最初のユーザーの変更は永久に保存されるか、2番目のユーザーの変更です）。これは完全に満足のいくものではありません。私はこの問題を解決するために、2つの可能性を検討し：最初はそれが誰かによって初めて開かれた文書をロックし、それが閉じているときに、ロックを解除することです

。しかし、サーバーへのネットワーク接続が突然中断された場合、文書は永久にロックされた状態にとどまります。明らかな解決策は、サーバーに定期的なpingを送信することです。サーバーが特定のクライアントからK行（K> 1）のK個のpingを受信しない場合、このクライアントによってロックされたドキュメントはロック解除されます。そのクライアントが再度表示された場合、文書がまだロックされていなければ、文書は再びロックされます。これは、クライアントアプリケーション（Webブラウザで実行中）が予期せず終了し、「終了して、自分のドキュメントのロックを解除する」信号をサーバーに送信できなくなる場合にも役立ちます。

第二は、異なるユーザによって保存された同じ文書の複数のバージョンを格納することです。文書への変更が連続して行われる場合、システムはバージョンをマージするか、または優先バージョンを選択するかのいずれかを提供する。ストレージスペースを最適化するには、ソース管理ソフトウェアと同様に、ドキュメント差分のみを保存する必要があります。

サーバーへの接続が（時には）が遅く応答しないことを考慮して、どのような方法を選択する必要がありますか？どのようにパラメータ（ping間隔、急速な連続間隔）を決定する必要がありますか？

P.S.残念ながら、私はデータベースにドキュメントを保存することはできません。

Answer 1

私の提案はあなたの最初のもののようになります。最初のユーザー（Bob）が文書を開くと、彼はロックを取得して、他のユーザーが現在の文書のみを読むことができるようにします。ユーザーがドキュメントを使用している間にドキュメントを保存すると、ドキュメントはロックされたままになります。彼が文書を終了するときだけ、それはロックされず、他の人がそれを編集することができます。

Bobがロックしている間に2人目のユーザー（Kate）がドキュメントを開くと、Kateはドキュメントが編集不可能だと言うメッセージを受け取りますが、ロックが解除されるまで読むことができます。

ボブがロックを獲得するときに何が起こる、多分一度か二度、文書が保存されますが、その後ロックぶら下げを残してアプリケーションを終了？

おそらく最良の選択肢である特定の周波数でpingを送信するためにロックを使用してクライアントを必要とする、自分で言ったように。設定した時間内にクライアントからpingを受け取らない場合、これはクライアントが応答しなくなったことを意味します。これがWebアプリケーションの場合は、pingにjavascriptを使用できます。最後に保存された文書はロックを解除し、Kateはこれを取得できるようになりました。

のpingは、クライアントがロックしているドキュメントの名前を含むことができ、かつその文書の最後のpingを受信したときにサーバーを計算することができます。第二は、楽観的なモデルである一方であなたが記述

Answer 2

最初のオプションは、基本的に悲観的ロック・モデルです。 どちらを選択するかは、実際にはさまざまな要因に左右されますが、基本的にはビジネスのしくみに変わりはありません。たとえば、編集する必要のある文書が別のユーザーによってロックされた場合、ユーザーに不都合な不便さを与えますか？ドキュメントがロックされていて、クライアントが接続して休暇を取るとどうなりますか？各ドキュメントの可能性のある競合は何ですか？つまり、同じドキュメントが同時に2人のユーザーによって変更される可能性はどれくらいですか？修正は単一のドキュメント内にどのようにローカライズされていますか？（同じセクションが定期的に変更されている場合、マージの実行には単に変更をやり直すより時間がかかります）。

競合が比較的低く、各変更のサイズがかなり小さいと仮定すると、自動または手動のマージを使用して競合を解決する楽観的なモデルを選択する可能性があります。ドキュメントの内容のバージョン番号またはチェックサムを使用して、マージが必要かどうかを判断できます。

Answer 3

現在、ドキュメントは限られたグループの人々によって公開されており、それぞれ別々のテーマで作業しています。したがって、ロックによって導入される不都合は最小限に抑えられます。 人々は大部分が既存の文書を拡張し、間違いを訂正します。

悲観的なモデルについて言えば、ロック開始日をロック開始日の1日前に設定することで、「N日間接続したクライアントを残した」シナリオを回避できます。編集されたドキュメントは決してミッションクリティカルではなく、複数のユーザーによって非常にまれにしか変更されないため、十分である可能性があります。

ここで楽観的なモデルを考えてみましょう。文書に規則的な（階層的な）構造がある場合、どのように違いが検出されるべきですか？そうでない場合は？これらのケースで自動マージが成功する可能性は何ですか？

「管理者」ユーザーグループによって編集されたドキュメントの一部に重要な構成情報（ドキュメントのグローバルインデックス、ユーザーの役割など）が含まれているため、状況がより複雑になります。私の考えでは、ロックは日常的に変更されていないので、この種の情報にはより有利です。したがって、いくつかのハイブリッドソリューションが受け入れられるかもしれません。

あなたはどう思いますか？