@SingletonセッションBeanがあります。Beanには。の注釈が付けられます。@ConcurrencyManagement( ConcurrencyManagementType.BEAN)
アノテーションを介してSessionContext注入されています。@Resource
これは本質的にスレッドセーフですかSessionContext（これは、非Bean管理の同時実行状況でも使用されるコンテナー生成オブジェクトであるため）、またはBeanがアクセスして操作するために、ロックで同期する必要がありますか？EJB 3.1仕様のセクション16.15.2では、注入されEJBContextたオブジェクトのスレッドセーフについては言及されていません。
コンテキストオブジェクトはスレッドセーフである必要があり、スレッドローカル変数を使用してこれをほぼ確実に実装します（実際、コンテナがスレッドローカル変数を操作していることに気付くと、Java EEの不思議な部分の多くを理解できます：java：comp 、セキュリティ、トランザクションなど）。それ以外の場合、EJBコンテナ実装がgetInvokedBusinessInterface、wasCancelCalledなどから信頼できる結果を返す方法は他にありません。
たとえば、スレッドセーフではないEJBContextの実装を想像してみてください。つまり、メンバー変数が呼び出され、EJBコンテナがBeanメソッドを呼び出す前に呼び出すsetInvokedBusinessInterfaceメソッドがあります。その場合、2つのシングルトンメソッドが同時に呼び出された場合、スレッドの1つは必然的にgetInvokedBusinessInterfaceから間違った答えを取得し、この問題を解決するBeanメソッドが適用できる同期の量はありません。
メーリングリストへのMarinaVatkinaによる投稿users@ejb-spec.java.netから：
EJBContextシングルトン以外のBeanでは、単一のスレッドによってのみアクセスされるため、スレッドセーフである必要はありません。セクション4.8.5シングルトンセッションBeanの同時実行で次のテキストを使用する場合、複数のスレッドが同時にそのシングルトンインスタンスにアクセスできる場合、コンテキストがスレッドセーフであることを確認するのは開発者の責任になります。「同時アクセスをサポートしないJavaEEオブジェクト（Java PersistenceエンティティマネージャーまたはステートフルセッションBeanへの参照など）をシングルトンセッションBeanインスタンス状態に格納することは合法です。ただし、そのようなオブジェクトを確保するのはBeanプロバイダーの責任です。一度に複数のスレッドからアクセスされることはありません。」