大きなトランザクションでの行ロック競合の問題

Question

SELECT FOR UPDATEを使用してデータベースからオブジェクトへのロックを取得する状況があります。これは、複数のテーブルから順序どおりの方法でレコードを挿入および削除するために必要です。この機能は、このように機能します。

ログイン - >一意のロックオブジェクトをロックし、複数のテーブルにレコードを挿入し、ロックを解除する - >ログアウト - >同じ一意のロックオブジェクトをロックし、複数のテーブルからレコードを削除してロックを解除する。

ログアウトする前にログインしたユーザーを追跡するための同期が有効になっています。 Javaコードでは注意が必要です。しかし、データベースレベルで別のロックを取得して、多数のユーザーがログインしているときにデータベーストランザクションが同期されるようにします。

問題：システム全体がマルチクラスタサーバーとシングルトンサーバーで完全に機能します。ただし、同時ユーザー数が4000以上になると、データベースにはrow lock contention（モード6）が表示されます。ログインできるユーザーはほとんどいません。

目的：ユーザーがログインして正常にログアウトできるように、ロック機構を修正します。

これまでに試したことがあります：NOWAITとSKIP LOCKEDからSELECT FOR UPDATEというクエリが追加されました。これは私の問題を解決しません。なぜなら最初のものは単にエラーをスローし、2番目のものは基本的に同期に影響するロックをスキップするからです。

この問題を解決するには、データベースの専門家からの提案や意見が必要です。 TIA。

更新：もう1つの情報を追加するだけです。ロックされた行は更新も何もしません。私たちが行う他のデータベースタスクを同期するためのメカニズムとして使用されています。

Answer 1

悲観的なロック（現在の方法）に頼る代わりに、おそらくORMを使用してオプティミスティックロックを使用します。