1

トランザクションを開き、OLE をスローする可能性のあるコードを try-catch ブロックに配置した場合、トランザクションを再開する必要がありますか? 私の答えは「はい」ですが、確証が得られないようです...

私のコードは基本的に次のようになります。

//start a hibernate transaction here
try
{
   //do things that are very likely to throw OLE
}
catch (Exception exc) 
{
   //just log it and do nothing else
}

//do something else that needs a hibernate session here (*)

私が (*) にいるとき、トランザクションがまだアクティブかどうかを確認する必要があるように見えますか?

4

2 に答える 2

0

これは、JPA 仕様に記載されている内容の抜粋ですOptimisticLockException。

  • DB に変更を書き込むときにバージョン チェックが行われるため、通常はコミット時に例外がスローされます。
  • 常にトランザクションにロールバックのマークが付けられます
  • 例外をキャッチして処理したい場合は、flush() を呼び出して、DB への書き込みを強制的に早期に発生させます。
  • 例外は、例外の原因となったオブジェクトを返す API を提供します。
  • 通常、古いオブジェクトを更新/再ロードし、トランザクションを再試行することで処理されます

完全を期すために、仕様の関連セクションのコピーを次に示します
(ドキュメントは .pdf 形式でのみ利用できるため、特定のリンクを提供することはできませんここ)。

3.4.5 OptimisticLockException

プロバイダーの実装は、有効なロック モードとフラッシュ モードの設定と一致する場合、トランザクションの終了までデータベースへの書き込みを延期する場合があります。この場合、オプティミスティック ロック チェックはコミット時まで発生せず、コミットの「完了前」フェーズで OptimisticLockException がスローされる可能性があります。OptimisticLockException をアプリケーションでキャッチまたは処理する必要がある場合は、アプリケーションでフラッシュ メソッドを使用して、データベースへの書き込みを強制的に実行する必要があります。これにより、アプリケーションは楽観的ロックの例外をキャッチして処理できるようになります。

OptimisticLockException は、例外がスローされる原因となったオブジェクトを返す API を提供します。オブジェクト参照は、例外がスローされるたびに存在するとは限りませんが、永続化プロバイダーが提供できる場合はいつでも提供する必要があります。アプリケーションは、このオブジェクトが使用可能であることに依存できません。

場合によっては、VM の境界を超えると、OptimisticLockException がスローされ、別の例外 (RemoteException など) によってラップされます。ラップされた例外で参照される可能性があるエンティティは、マーシャリングが失敗しないように Serializable を実装する必要があります。

OptimisticLockException は常に、トランザクションにロールバックのマークを付けます。

オブジェクトを更新するか、新しいトランザクション コンテキストでオブジェクトを再ロードしてから、トランザクションを再試行すると、OptimisticLockException への応答になる可能性があります。

于 2013-08-14T16:13:31.760 に答える