3

私は単純な Java EE 5 の「ルーティング」アプリケーションを開発しています。MQ キューからのさまざまなメッセージが最初に変換され、特定のフィールドの値に従って、さまざまなデータ ソースに格納されます (さまざまな ds のストアド プロシージャを呼び出す必要があります)。

たとえば、valueX -> dataSource1、valueY -> dataSource2 です。すべてのデータソースは、異なる jndi エントリを使用してアプリケーション サーバーにセットアップされます。通常、アプリの実行中にルーティング情報は変更されないため、データソース ルックアップをキャッシュするために保存しますか? たとえば、valueX->DataSource1 を格納するハッシュマップを保持するシングルトンを実装します。特定のエントリがリストにない場合は、リソース ルックアップを実行し、結果をマップに保存します。キャッシュを使用するとパフォーマンスが向上しますか? または、これらのリソース ルックアップは十分に高速ですか?

一般的に、この種のキャッシュを構築する最良の方法は何ですか? 他のデータベース検索にもキャッシュを使用できます。たとえば、マッピング valueX -> リソース名は、DB の単純なテーブルで定義されます。必要に応じて値を検索して結果をマップに保存するか、常に検索を行うか、起動時にすべてのエントリを読み取って保存する方がよいでしょうか? アクセスを同期する必要がありますか? 「列挙」シングルトン実装を作成できますか?

4

1 に答える 1

4

運用/変更管理の観点からは安全ですが、プログラマーの観点からは安全ではありません。

プログラマーの視点から、DataSource 構成は実行時に変更できるため、常にルックアップを繰り返す必要があります。

しかし、これは実際の生活で起こっていることではありません。

データソースへの変更が実装される場合、これは変更管理手順によって行われます。ac/r レコードがあり、そのレコードには、アプリケーションにダウンタイムがあると記載されています。つまり、c/r を実行している運用担当者は、アプリケーションを停止し、変更を行って、元に戻します。安全上の理由から、誰もライブ AS でこのような変更を行いません。そのため、実行時に DS が変更される可能性を考慮に入れる必要はありません。

したがって、永続的に同期された共有キャッシュは、この場合に適しています。

パフォーマンスが向上しますか？これは、AS の実装によって異なります。独自のキャッシュを持っている可能性がありますが、そのキャッシュはより一般的で低速である可能性があり、実際にはその存在をまったく期待できません。

キャッシュを構築する必要がありますか? 答えは通常、パフォーマンス テストから得られます。問題がなければ、時間を無駄にしてリスクを導入する必要はありません。

再開: はい、単純なキャッシュを構築して使用します -- パフォーマンスの向上によって正当化される場合。

実装の詳細は、好みによって異なります。私は通常、オンデマンドでルックアップを行うキャッシュを持っており、内部に jndi->object の同期されたマップがあります。並行性の高いキャッシュの場合、単純な同期の代わりに読み取り/書き込みロックを使用します。つまり、新しいエントリを追加すると排他アクセスを取得しながら、多くの読み取りを並行して行うことができます。しかし、それらはアプリケーションの詳細に大きく依存する詳細です。

于 2011-04-24T18:52:05.477 に答える