1

  1. シングルトン セッション Bean は、どのような問題に対処するために導入されましたか?? すべての Bean に共通するデータを共有するためだけですか??

  2. この問題は、EJB 3.0 およびそれ以前のバージョンではどのように管理されていますか?

  3. クライアント固有の会話状態を保持している場合、その単一のインスタンスには、すべてのクライアント (同時にアクセスしようとしている) 固有のデータが含まれますか?? 安全になりますか??

  4. Bean 間で共通データを共有するために、他のセッション Bean で静的最終変数と静的初期化子ブロックまたは静的メソッドを使用してそれらを初期化できる場合 (静的変数はインスタンス データごとではなくクラス データごとでもあるため)、シングルトン セッションの必要性は何ですか?豆 ？

  5. シングルトンにビジネスメソッドを持たせるのは良い設計ですか?? その場合、単一のインスタンスによって処理されるクライアント リクエストの応答時間は、複数のインスタンスによって処理される場合よりもはるかに長くなります。

    さらに、シングルトン Bean は複数のクライアントによる単一の Bean インスタンスへの同時アクセスを許可しますが、デフォルトの同時実行タイプ (コンテナー管理) のデフォルトのロック タイプ (書き込みロック) は、そのメソッドが終了するまで、他のすべてのスレッドが Bean にアクセスするのをブロックします。そして、これは不利なようですよね??

  6. 他の Bean がシングルトン Bean とまったく同じように適合しない明確で単純なユースケースを誰かが提供できれば、非常に役立ちます

前もって感謝します ：）

4

1 に答える 1

4

  1. はい。

  2. 通常、データは静的変数に格納されていました。単体テストを含むさまざまな理由から、静的変数はあまり適していません。さらに、静的変数にはある種の同期が必要であり、EJB 仕様を厳密に読むと、実際には問題なく動作していましたが、それが許可されていません。

  3. 通常、シングルトンに格納される状態はクライアント固有ではなく、アプリケーション固有です。たとえば、グローバル構成状態のキャッシュまたはデータベースからのグローバル状態のキャッシュ、おそらく定期的な非永続タイマーによる更新などです。

  4. ありませんが、#2 を参照してください。

  5. いいえ、シングルトン Bean は、おそらく要求ベースのビジネス ロジックには適していません。はい、デフォルトは WRITE ロックを使用した CONTAINER 同時実行であるため、一度に 1 つのスレッドのみです。@Lock(READ)または必要に応じて使用する@ConcurrencyManagement(BEAN)必要があります。

  6. #3 で述べたように、通常、すべての Bean で共有する必要がある「グローバル」なアプリケーション状態です。シングルトン セッション Bean は、アプリケーションの構成やアプリケーション全体のタイマーの管理に便利です。

于 2015-05-13T04:21:58.100 に答える