httpsession オブジェクトに大量のデータが読み込まれないようにするには、どのような手法を使用する必要がありますか。
例 ：
リクエスト 1 ---- > 50,000 の異なるオブジェクトの配列リストをロードした httpSession。session.setAttribute("データ",arraylist);
リクエスト 2 ---- > 40,000 の異なるオブジェクトの配列リストをロードした httpSession。session.setAttribute("データ",arraylist);
サーバーが複数のセッションとそれらの巨大なデータで非常に負荷が高いと仮定します。上記の例から、一度に request1..1000 としましょう。これは、膨大なデータを含む 1000 個のセッション オブジェクトを意味します。
このようにセッションに保存する代わりに解決する別の方法は何ですか?
いくつかのアイデア:
クライアントに実際に提供する必要があるデータをより選択してください。最初のリクエストでセッション内のすべてをポンピングするのではなく、クライアントが本当に必要なときにのみデータをロードできます (タブがユーザーによってクリックされたとき)。完全なバックエンド ドメイン クラスの代わりに特殊な軽量クラスを使用して、データをフロントエンドに渡すこともできます。
ドメイン モデルを確認し、「静的データ」を分割できるかどうかを確認してください。これは、郵便番号のように、アプリケーション内で一般的に共有され、あまり変更されないデータを意味します。このタイプのデータは、複製するのではなく、キャッシュして参照渡しするのに適しています。
前述のように、Ehcache などのキャッシング フレームワークを使用します。これにより、アプリケーションでコードを配管する必要が減り、データを複製する代わりに、すべてのセッションでキャッシュを共有できます。もちろん、セッションにユーザー固有のデータのみを保存している場合は、共有しても大きなメリットはありません。このようなフレームワークでは、たとえば、必要に応じてデータベースの使用を開始するように、キャッシュ戦略を構成することもできます。
代わりにアプリケーション スコープに入れるか (ユーザー固有でない場合)、要求ベースのデータベース側のページング/フィルター処理に置き換えます (ユーザー固有の場合)。
データはすでにデータベースに保存されていると思います。それをアプリケーションスコープに入れることはあまり意味がありません。Java コードがデータストア (RDBMS など) のデータセット全体を Java のメモリに移動/コピーし、Javaコードを使用して Java のメモリでジョブを実行すると、常にメモリの問題が発生します。Webアプリケーションのセッションスコープに保存/複製すると、さらに悪化します。
最もメモリ効率の良いアプローチは、データベースが発明されたタスクをデータベースに実行させることです。SQL 言語はORDER BY、ソートを実行する各節WHERE、フィルタリングを実行する節、および (DB ベンダー固有の)節/副選択/関数を提供して、 firstrowとrowcountまたはlastrowLIMIT/OFFSETに基づいてレコードのサブセットのみを返します。このようにして、実際に表示されるJavaのメモリ内のデータセットのみが得られます。
必要な SQL クエリの例は、私が以前ここに投稿したこの回答で見つけることができます。お役に立てれば。
共有プールにあるオブジェクトの一意の識別子のみを保存します (メモリ、データベース、フラット ファイル)
ビューでデータを使用する場合は、リクエストに属性を設定するか、フォームを使用できます。セッションがアクティブなときにデータが必要な場合は、データベースに入れます。