Java EEを使用しています。そして、最悪の場合、多数のメッセージ キュー メッセージが同じユーザーから送信されるアプリケーションを作成しています。
したがって、悲観的な SELECT FOR UPDATE スタイルのロックを検討しています。理論と最初のテストでは、これが問題を解決します。
しかし、私たちはデッドロックを恐れています。古典的なものではありません: ユーザー X は A をロックし、ユーザー Y は B をロックします。原因不明のデータベース システムのロック。Oracle、MS SQL、postgresql などの最新のデータベースを使用します。
私たちが知りたいのは、本番環境で使用される悲観的ロックと、予想される実際の問題は何ですか?
前もって感謝します！
悲観的ロックで私が見た最悪の問題は、データベースが必然的にボトルネックになることです。
つまり、コードがアプリ レベルでデッドロックを防止している場合 (投稿で述べているように)、パフォーマンスが問題になります。一度に 1 人のユーザーしか特定のデータ セットに対して更新を実行できないため、スループットが低下します。
が実行されたがコミットされていないなどのシステム例外が発生した場合、ロックされたテーブルがロックされたままになる可能性がありますが、select for update一般的にこれは一般的ではありません (ただし、これは明らかにコードによって異なります)。これがインフラストラクチャ関連の問題で発生するのを見たことはありませんが、アプリケーション エラーによってのみ発生します。
可能であれば更新をバッチ処理することでスループットの問題をある程度軽減できますが、これは実際には特定の状況に依存します。