Web レイヤーでリモート EJB ルックアップを実行し、初期コンテキストをキャッシュする状況があります。これで、リモート EJB が WAS クラスターにデプロイされました。そのため、リモート ejb が server1、server2、および server3 にわたってデプロイされ、最初に言うと、server1 を指す初期コンテキストがキャッシュされます。
このサーバー1がダウンした後、他のサーバーはまだ稼働しています。ただし、初期コンテキストがキャッシュされるため、ejb 呼び出しは失敗します。
簡単な解決策は、キャッシュを削除して毎回新しいルックアップを行うことです。しかし、それはパフォーマンスを低下させます。信頼性とパフォーマンスの両方の長所を活かす方法はありますか?
プロバイダー URL内のブートストラップ サーバーのリストは、が構築corbaloc:されている場合にのみ使用されます。InitialContextコンテキストの構築中に、クライアントはそのコンテキストのルックアップに応答できるサーバーのリストを取得し、その後はそのリストのみが使用されます。プロバイダ URL のブートストラップ サーバがクラスタ メンバである場合、InitialContext少なくとも 1 つのクラスタ メンバが実行されている限り、 は引き続き機能します。したがって、InitialContext安全にキャッシュできます。
プロバイダー URL のブートストラップ サーバーがクラスター メンバーではなくノード エージェントである場合は、状況が異なることに注意してください。その場合、 はInitialContext単一のノード エージェントに固有のコンテキストを参照し、そのノード エージェントがダウンするとルックアップは失敗します。これは、プロバイダー URL で複数のノード エージェントが指定されている場合でも当てはまります。ノード エージェントの 1 つが の構築中にInitialContext選択され、選択はその後変更されません。