2

私たちのアプリは主に、Hibernate のバージョン管理サポートを使用した楽観的ロックを使用しています。特定のシナリオで悲観的ロックを実装する予定です。私は悲観的ロックの経験があまりないので、この質問がナイーブに聞こえる場合はご容赦ください。

ユーザーがエントリを更新する意図を示した場合、「select for update」を使用して対応する DB 行をロックします。さて、このユーザーが変更をコミットするのに長い時間がかかり、ロック後にそれを忘れてしまった場合、タイムアウト/ロールバック メカニズムを使用してこのロックを解除するにはどうすればよいでしょうか? 行が非常に長い間ロックされたままになり、他のすべてのユーザーがその行を編集できなくなることがないようにします。

これが、私たちが使用している Weblogic-JTA-Spring トランザクション メカニズムで処理されるかどうかは疑問です。ここでは、既に 30 分のトランザクション タイムアウトがあります。(??)

したがって、このロールバックは Oracle レベルで直接処理する必要があります。はいの場合、どのように？このようなロックが長く残りすぎないように、これを処理する最善の方法についてアドバイスしてください。

4

2 に答える 2

2

ロックは、トランザクションが終了したときにのみ解放されます。トランザクションは、明示的commitまたはrollbackデータベースに発行されたとき、またはデータベースセッションが終了したときに終了します（暗黙的に実行されますrollback）。中間層が30分を超えて開いているトランザクションをロールバックするようにすでに設定されている場合は、ロックを解除するのに十分です。

ただし、WeblogicアプリケーションサーバーでJavaアプリケーションを実行している場合は、悲観的なロックが適切であるとは思えません。まず、中間層で接続プールを使用していると仮定します。その場合、接続プールからの1つのデータベース接続は、トランザクションの長さ（この場合は最大30分）の間、中間層によって保持される必要があります。ただし、1つのセッションで特定のデータベースセッションを長期間開いたままにしておくと、接続プールを持つという目的が無効になります。通常、数百ではないにしても数十のアプリケーションセッションが接続プールからの単一の接続を共有できます。悲観的なロックを許可する場合は、アプリケーションセッションとそれらのセッションのデータベースセッションの間に1：1の関係を強制します。

于 2013-01-24T14:50:43.193 に答える
0

楽観的ロックが悲観的ロックに取って代わることができない場合が数多くあります。ロック タイムアウトはデータベースで処理されます。Oracle での設定方法については、このページを参照してください。

Oracle のデフォルトのオブジェクト ロック タイムアウトは変更できますか?

于 2015-07-09T17:20:05.833 に答える