WebSphere® eXtreme Scale は、データが存在する場所にロジックを移動し、結果のみをクライアントに戻すことによって、高い処理速度を実現します。
クライアント Java 仮想マシン (JVM)のアプリケーション論理では、データを保持しているサーバー JVM からデータをプルして、トランザクションがコミットされた時点でそのデータをプッシュ・バックすることが必要になります。 このプロセスにより、データが処理されるレートが低下します。アプリケーション・ロジックが、 データを保持している断片と同じ JVM 上に あれば、ネットワーク待ち時間およびマーシャル・コストはなくなり、 パフォーマンスは大幅に向上します。
ObjectGrid API には、サーバー・サイド・メソッドに対するセッションが用意されています。このセッションは、その断片のデータに対する直接のリファレンスになります。そのパスでは、ルーティング論理は存在しません。アプリケーション論理は、直接その断片のデータとともに作業できます。ルーティング論理が存在しないため、別の区画のデータにアクセスするのにセッションは使用できません。
Loader プラグインには、断片がプライマリー区画になる場合にイベントを受信する方法が用意されています。アプリケーションは、ローダーおよび ReplicaPreloadController インターフェースを実装できます。検査プリロード状態メソッドは、断片がプライマリー区画になる場合にのみ呼び出されます。そのメソッドに提供されているセッションは、断片データに対するローカル・リファレンスです。これは、区画が主に一部のスレッドを開始したり、区画に関連するトラフィックのメッセージ・ファブリックに加入したりすることを必要としている場合に、通常使用される手法です。getNextKey API を使用して、ローカル・マップ内でメッセージを listen するスレッドを開始します。
アプリケーションがクライアント API を使用し、そのクライアントが含まれる JVM と連結されることになる区画にアクセスする場合は、ネットワークは回避されますが、現行の実装問題のためマーシャルが発生する場合があります。区画に分割されたグリッドが使用されている場合は、(N-1)/N 個の呼び出しが異なる JVM に送付されるため、アプリケーションのパフォーマンスに影響は与えません。常に断片を伴うローカル・アクセスが必要な場合は、ローダーまたは ObjectGrid API を使用してそのロジックを呼び出します。