0

「のスレッド内のスコープ付きプロキシ Bean へのアクセス」の回答からのアプローチを使用しています。ただし、オブジェクトに関連するまれなデッドロックが発生していRequestAttributesます。デッドロックの主な原因はsynchronized (this.sessionAttributesToUpdate)、オブジェクト内のステートメントとサーブレット セッション ハッシュ マップの間にあります。通常、オブジェクトのインスタンスはリクエストごとに作成されるため、衝突することはありませんが、セッション Bean を使用するためにオブジェクトを別のスレッドに渡すと、同じオブジェクトが使用され、デッドロックが発生することがあります。

で渡されたセッション Bean の使用を別のスレッドが開始している間に、現在の http 要求が完了していない場合、デッドロックが発生しRequestContextHolder.setRequestAttributesます。

この男は同じ問題に言及していると思いますが、彼の質問には答えがありません:セッション スコープ Bean がデッドロックに遭遇しました。

それで、デッドロックを回避する方法はありますか？

4

1 に答える 1

0

ユーザーがページをナビゲートしている間にバックグラウンドで何かを計算することが目的であることを考慮して、代替ソリューションを提供する回答を次に示します。

可能性 1: @Async でアノテーションが付けられた処理メソッド ( http://static.springsource.org/spring/docs/3.0.x/reference/scheduling.html ) を使用して、Future で計算の結果を返すサービス Bean を作成する物体。Future オブジェクトをセッションに格納します。タスクが完了した場合、Future オブジェクトを介して後続のリクエストで結果にアクセスします。タスクが完了する前にセッションが破棄される場合は、Future.cancel を介してタスクをキャンセルします。

可能性 2: Spring 3.2 および Servlet 3.0 非同期処理の新機能が役立つかどうかを確認してください: http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/mvc.html #mvc-ann-async

可能性 3: タスク キューをエミュレートします。オブジェクトを ConcurrentMap のような構造に配置できるシングルトン サービスを作成します。この場合、キーはジョブ ID であり (キーをセッションに保存することもできます)、バックグラウンド処理の結果を評価します。バックグラウンド スレッドはそこにオブジェクトを格納します (これは、セッションに直接アクセスするよりも優れているとは言えませんが、スレッド セーフであることを確認できます)。

于 2013-04-02T18:00:20.040 に答える