多くの情報を持つユーザーのプロファイルを保持する必要があるWebアプリケーションを設計しています.明らかにデータベースからデータを読み取ります.
現在、私は自分のセッションにユーザー名を持っており、ユーザーの情報が必要になるたびに、セッションを読み取り、(データベースからデータを再度読み取る) プロファイル クラスのオブジェクトを作成して、ユーザーの情報を取得する必要があります。このような問題のベスト プラクティスですか? ?
一般に、「ベスト プラクティス」は、ユーザー プロファイル データをセッションで維持し、必要なすべての情報をデータベースから初めてロードすることです。
つまりProfile
、http セッションでクラスのインスタンスを管理します (実装する必要がありますSerializable
)。プロファイルは、より頻繁に使用されるすべての情報を保持する必要があります。
「セッションの読み取り」は、HashMap の読み取りに似ていることに注意してください (したがって、パフォーマンスの点で最小のコストがかかります)。のHttpSession
有効期限が切れると、プロファイルはガベージ コレクションされます。
更新(コメントに基づく):
アクティブなユーザーをカウント (または検索) するには (非アクティブなユーザーは他のすべてのユーザーです)、典型的な解決策はインターフェイスをProfile
実装することです。HttpSessionBindingListener
がセッションにバインドProfile
されると通知されるので、静的カウンター (たとえば、Profile クラスの静的属性) をインクリメントできます。Profile
これは、パフォーマンスとメモリ消費の間の典型的なトレードオフです。高速なアプリケーションが必要な場合は、ユーザー プロファイル全体を HTTP セッションに保持しますが、サーバーに十分なメモリがあることを確認してください。
リソースの消費を低く抑えたい場合は、ユーザー ID のみをセッションに保存し、必要なときにデータベースからロードします。これにより、移行するデータが少なくなるため、クラスタリングも簡単になります。
妥当な妥協点は、後者のアプローチをキャッシュとともに使用することです。このようにして、使用頻度の高いユーザー (現在システムを使用している) はメモリに保持されますが、アイドル状態のユーザーや新しいページに頻繁にアクセスしないユーザーはキャッシュから一掃されます (キャッシュが HTTP セッションの数よりも小さいと仮定します)。
Obe6 の回答に同意しました。プロファイルがセッションにない場合は、データソースから取得してセッションにアタッチすることをお勧めします。
セッションが無効になると、すべての情報がセッションから削除されます。これに関する IBM の優れた記事があります。 http://www.ibm.com/developerworks/websphere/library/bestpractices/store_objects_in_httpsession.html
通常、セッションは、ユーザー プロファイル データを保持するのに十分な場所です。ここで話しているデータの量を定量化する必要があります。セッションごとに 5KB とすると、100 MB の RAM を使用して最大 20000 のユーザー プロファイルをメモリに格納できます。最大に基づいて、それに応じてヒープをJVMに割り当てることができます。サイトで予想されるアクティブなセッションの数。
これは 1 つの側面にすぎません。アプリ サーバーを追加してアプリをスケーリングする場合は、memcached などのプロセス外のキャッシュ/メモリ ストアにセッションを移動することも考えられます。
セッションに保持しているすべてのユーザー プロファイル データが各ページにレンダリングされない場合は、セッションで最小限のデータのみを保持し、必要に応じて他のデータを取得することをお勧めします。