1

私たちのプロジェクトは EJB 2.0 で設計されています。

BMP EntityBeans では、いかなる種類の EJB 永続化メソッドも使用していません。SessionBeans では、メソッド getEJBXXXXHome() メソッドを使用して EntityHome オブジェクトへの参照を取得し、そこで home.findByPrimaryKey("") メソッドを呼び出して EJB 参照を取得します。次に、CRUD 操作の実際のメソッドを呼び出します。CRUD 操作メソッドでは、通常の JDBC API メソッドを使用しています。

現在、EJB3 に移行しています。EJB 2.0 から EJB3 への移行の一環として、すべての BMP エンティティ Bean を通常の Java クラスに変換しています。つまり、エンティティ Bean はもうありません。以前に EJB コンテナがエンティティ Bean のプールを保持していた場合、現在は存在しません。ローカル マシンで 1 つのトランザクションをテストしたところ、正常に動作していました

私の懸念は、本番環境で複数のスレッドのパフォーマンスに影響を与えることですか?.

ここでコードを変更すると、呼び出しごとに 1 つの EntityBean オブジェクトが作成されます。わずか 1 時間で 60,000 回の呼び出しが行われた場合、サーバーに影響します。これは、EJB 2.0 で以前はどのように処理されていましたか? 変更されたコードでそれを処理する方法はありますか (つまり、エンティティ Bean の概念がなくなったため、通常の Java クラスの場合)

4

1 に答える 1

1

一般的に言えば、異議の作成/収集のオーバーヘッドは、EJB コンテナーが以前にエンティティに対して行っていたオーバーヘッドよりも低くなります。オブジェクト作成のオーバーヘッドよりも大きな問題は、データベースへのラウンドトリップだと思います。EJB コンテナーの構成によっては、コンテナーが JDBC SQL を最適化し、取得したデータをキャッシュしていた可能性があります (オブジェクトのキャッシュとは関係ありません)。データベースへの呼び出しを最小限に抑え、不要なクエリを実行しないようにアプリケーションを設計する必要があります。

最終的には、ハードウェア上のアプリケーション サーバーでアプリケーションのパフォーマンスを評価できるのは、あなただけだと思います。事前にパフォーマンスを心配するのではなく、ひどいオーバーヘッドを回避し、結果をプロファイリングし、そこから最適化するために、適切なプログラミング プラクティスに従うことをお勧めします。

于 2013-06-07T14:51:54.697 に答える