データベースに存在しないレコードを削除する際にorg.hibernate.StaleObjectStateExceptionをキャッチできません

私のアプリケーションには、ユーザーの削除オプションがあります。今、並行性の条件をチェックするために、私は次のユースケースを試しました

  1. クロームとFirefoxブラウザでアプリケーションを開いた。
  2. Firefoxで削除されたユーザー
  3. クロムブラウザで同じユーザーを削除しようとしています。存在しないオブジェクトを削除しようとしているので、例外は org.hibernate.StaleObjectStateException しかし、私はこの例外を捕まえることができません。

try{
   getHibernateTemplate().delete(userObj);
} catch (StaleObjectStateException e) {
   e.printStackTrace();
}

どのように私はこの例外をキャッチしますか?

2

3 答え

例外をスローするのは削除呼び出しではなく、後で実行される(クエリの実行前またはトランザクションのコミット前に)セッションのフラッシュですので、そこにキャッチすることはできません。

Hibernateが例外をスローすると、セッションをもう使用できなくなるため、この例外は捕捉してはいけません。これは不安定な状態です。そのような例外がキャッチされるアプリケーションの唯一の部分は、エラーメッセージをユーザーに表示するため(または再試行しますが、この特定の場合は不可能です)、トランザクションの外にあります。

5
追加された

あなたの質問のコードは、それに直面しています。

そのdelete呼び出しが実際に実行されたときにその例外をスローすると、コードはそれをキャッチします。そうでない場合、例外は実際には別の場所でスローされています...またはスローされている例外は異なるものです。

私は java.lang.Throwable のキャッチでキャッチを一時的に置き換えて、その時点で他の例外が伝播しているかどうかを確認します。また、トレース・プリントを追加して、コードがまったく実行されているかどうかを確認します。

既にスタックトレースがある場合は、何か本当に面倒なことが起こっていない限り、例外がスローされている場所がわかります。あなたはちょうどスタックの上にそれをキャッチする必要があります。

0
追加された
試してみました..それは動作しません..
追加された 著者 JAB,

あなたはStaleStateExceptionの代わりにStaleObjectStateExceptionをキャッチしています:-)

更新: stacktraceを見てください。トランザクションで作業していると仮定すると、例外はトランザクションがコミットされたときにだけスローされます。

0
追加された
申し訳ありませんが、私は実際にorg.hibernate.StaleObjectStateExceptionを取得する例外を編集しました。
追加された 著者 JAB,
私はトランザクションで働いています。私は、トランザクションがコミットされたときに例外がスローされると感じます。それをキャッチする方法を知らない
追加された 著者 JAB,