hibernateの楽観的/ペシミスティックなロックを伴う同時実行性の良い戦略/解決策

Question

アプリケーション "メールクライアント"とそのフロントエンドがあるとしましょう。

ユーザーがメッセージを入力したり、件名などを編集している場合、メッセージをDRAFTに保存するために、ユーザーが変更したもの（受信者など）を更新するための残りの呼び出しが行われます。だから、たくさんのPUTがメッセージを保存しようとしています。ウィンドウを閉じると、編集可能なすべてのフィールドの更新が同時に行われます。 Hibernateはこの並行処理を処理できません。これらの呼び出しのそれぞれは、メッセージを取得し、独自のフィールドを編集し、メッセージを再度保存しようとします。

私はすべてのフィールドを同時に保存するために休憩の呼び出しを追加できることは知っていますが、クリーナーソリューションがあるかどうか、またはそのようなケースを処理するためのまともな戦略があるかどうか疑問に思っていましたオブジェクトが既に変更されている場合は、マージ戦略）

ありがとうございます！

Answer 1

最も簡単な解決策は、ここではどちらか

• が必要なすべてのタスクを実行し、電子メールの提出時に、単一REST呼び出しを送信するためにUIを微調整することであろう。
• 残りの呼び出しをシリアル化して、同時に呼び出すのではなく連鎖させるようにします。

私がここで気になっているのは、これはある時点で雪が降り、より多くのユーザーがアプリケーションとやりとりしているため、より大きな並行性の問題になるということです。 100万人、500人、1000人、さらには10000人以上の同時ユーザーに直面しているときに、Webインフラストラクチャが単独でサポートしなければならない潜在的な並行休憩の可能性があると考えてください。

負荷自体が最初に設計上の欠陥の製品である場合、その負荷を処理するためにサーバーのボリュームを強化するのは本当に意味がありますか？

Hibernateは、楽観的で悲観的な2つのメカニズムを介してロックを処理するように設計されています。

楽観ウェイ

1. データストアからエンティティを読みます。
2. 一時変数で変更するフィールドのコピーをキャッシュします。
3. PUT操作に基づいてフィールドを変更します。
4. 変更をマージしようとしました。
5. 保存が成功すると、完了です。
6. OptimisticLockExceptionが発生した場合は、データストアからエンティティの状態をリフレッシュしてください。
7. キャッシュされた値を変更する必要があるフィールドと比較します。
8. 値が異なる場合、彼らは楽観アプローチの美しい部分は、あなたが任意の形式を避けるためであるバック4.

に行く、異なっていない場合は、例外

を主張するか、投げることができますデッドロックが発生します。特に、複数のテーブルを個別に読み取ってロックする場合は特にそうです。

悲観的なロック・オプションを使用することはできますが、一般に、同時実行の競合およびパフォーマンスの影響が最も少ないため、オプティミスティック・ロックが最も一般的な方法です。