2

EJB 2.1 SLSB として実装された使用頻度の高いサービス オブジェクトを想像してみてください。これは、まったく状態を持たないため、たまたまそれ自体がスレッド セーフになっています。すべてのパブリック メソッドは (CMT を介して) トランザクションに対応しており、ほとんどは単純にトランザクションを必要としますが、新しいトランザクションを必要とするものもあります。

この SLSB を本物のシングルトン POJO に変換すると (DI フレームワークなどを使用して)、アプリケーションのスケーラビリティにどのような影響がありますか? サービスが SLSB の場合、EJB コンテナーはインスタンスのプールを管理し、そこから各クライアントが独自のコピーを取得するため、それをシングルトン POJO にすると、その単一インスタンスに何らかの競合が発生するのではないかと考えています。

FWIW、このサービスのメソッドはどれもsynchronized.

明確化: SLSB を POJO に変換する私の動機は、オブジェクトのライフサイクル (真のシングルトンとコンテナー管理) とコード自体 (1 つのインターフェースと 1 つの注釈付き POJO に対して、3 つのインターフェース、1 つの Bean クラス、および束) の両方の単純さです。 XML の ejb-jar.xml 内)。

また、FWIW、問題のサービスは、JBoss 3.x で実行されているコロケーションされた Web アプリの 1 つのコンポーネントです。

4

2 に答える 2

3

POJOが本当にステートレスであるか、会話状態がない場合（つまり、状態が不変である場合）、パフォーマンスが低下することはなく、コンテナのプールではなく、DIフレームワークのインスタンスを1つだけ使用しているため、わずかに向上する可能性があります。 。（プールでさえ、高負荷の下で競合に苦しんでいます。）

状態がまったくない、または単に不変であるオブジェクトなど、設計上スレッドセーフなオブジェクトには同期は必要ありません。競合は発生しません。スレッドは同期せずにPOJOでメソッドを自由に実行できます。

POJOだけを使用することで、アプリで何が起こっているかを実際に確認でき、舞台裏で隠れた「コンテナマジック」が発生していないことを確認できます。

于 2010-07-06T09:23:08.293 に答える
1

あなたの POJO は完璧に見えます。

いいえ、競合はありません。スケーラビリティは完璧です。

  • 追加費用はかかりません。
  • 複数ではなく 1 つのインスタンスがあるため、さらに少なくなります。
  • プールの制限に達することがないため、スケーラビリティが向上します (持っていません)。
于 2009-10-09T07:45:57.163 に答える