私が取り組んでいるプロジェクトに奇妙なコードがあることに気付きました.SLSB EJB3であり、getter/setterを使用してデータのキャッシュを維持するためにプライベートインスタンス変数を使用しています(dataCacheなどとも呼ばれます)。EJB2 および次の場合、これは典型的な EJB アンチパターンでした。SLSB は呼び出し間で状態を保持することを意図していないため、後続の呼び出しで同じデータが表示されるという保証はありません。私の同僚の 1 人は、EJB3 では問題ないかもしれないと言っていましたが (EJB3 の経験はあまりありません)、それでもステートレス セッション Bean です - なぜ状態を維持しようとするのか、これは意味がありません。
これがEJB3の世界ではまだ悪い考えなのか、それとも何とか大丈夫なのか、誰でも確認できますか?
助けてくれたらありがとう、ジャスティン
@SingletonEJB 3.1では、個別のシングルトンBean（アノテーション付き）を用意し、それを介し@EJBてそれを必要とするセッションBeanに注入することで、これをきれいに行うことができます。
EJB 3.1より前は、本当にクリーンな方法はなく、何らかのハックを使用する必要があります。
EJB2 および次の場合、これは典型的な EJB アンチパターンでした。SLSB は呼び出し間で状態を保持することを意図していません。後続の呼び出しで同じデータが表示されるという保証はありません。
これは真実であり、これはどういうわけか臭いです (誤って使用されることが多いため: 人々は、同じインスタンスを取得する保証がないこと、コンテナーがプールから一部の Bean を削除してリソースを解放できること、Bean が全体に分散される可能性があることを忘れがちです) JVMなど）。
私の同僚の 1 人は、EJB3 では問題ないかもしれないと言っていましたが (EJB3 の経験はあまりありません)、それでもステートレス セッション Bean です - なぜ状態を維持しようとするのか、これは意味がありません。
EJB 2.x のステートレス セッション Bean (SLSB) に当てはまったことは、EJB 3.0 でも当てはまります。SLSB は依然として SLSB であり、EJB 3.0 はステートレスを再定義しませんでした。
ただし、インスタンス変数を使用して、読み込みにコストがかかる読み取り専用リソースを保持する場合 (および場合は必ず読み込むようnullにしてください)、問題ありません。