@FlowScoped Bean を使用して小さな実験を行いました。その目的は、私が理解しているように、「ウィザード型」の Web アプリケーションの作成を容易にし、一連のページでデータを徐々に蓄積し、すべてのデータの準備ができたら、書き込みます。それを永続ストレージに保存します (これは単なる例です。もちろん、中間ステップで永続ストレージに書き込むことを妨げるものは何もありません)。私が見たように、@FlowScoped Bean への呼び出しは同期されていないため、原則として、Bean に保存されているデータが破損する可能性があります (二重送信を行うか、他の方法でほぼ同時に 2 つの HTTP 要求を起動することにより、 Bean のメソッドを呼び出す)。これは、呼び出しが同期される @ConversationScoped Bean とは異なります。
私を困惑させているのは、 @SessionScoped Bean について、 @SessionScoped Bean へのアクセスを同期する必要性について話しているリンクをいくつか見つけたことです (または、めったに変更されないユーザーデータを除いて、それらをまったく使用しないことをお勧めします)。 @FlowScoped Bean についてそのようなものは見つかりませんでした。
@FlowScoped Bean を使用するための「ベストプラクティス」と見なされるものは何ですか? 何か不足していますか？
編集
@FlowScoped は、少なくとも私には、Spring WebFlow によって部分的に動機付けられているように見えます。Spring WebFlow にはある程度の経験があり、私が知っているように、JSF 2 との統合を提供します (すべての JSF 2.2 機能が実装されているわけではありませんが、たとえば、PrimeFaces が使用できるようです)。Spring WebFlow + JSF が実際に「実世界」のアプリケーションで使用されており、フロー スコープ オブジェクトのスレッド セーフの問題が二重送信の問題とともにエレガントに処理されていることを私は知っています (フロー実行 ID は各 HTTP 要求で提供する必要があり、 Spring WebFlow の「アクション」メソッドを呼び出す HTTP リクエストの後に期限切れになり、新しいものが返されます。したがって、同じユーザーとフロー ID に対して複数の「アクション」メソッドを同時に呼び出すことはできません)。
したがって、@FlowScoped Bean を使用してアプリケーションの「フロー」を構築したい場合 (Spring WebFlow を使用せずに)、JSF 2.2 の場合のベストプラクティスは何かを理解したいと思います。@FlowScoped Bean へのアクセスを自分で同期する必要がありますか、それともそのような問題に対処するための標準的な方法がありますか?