2

XPages Web アプリケーション (Xpages は JSF ベースの Lotus Notes テクノロジー) では、セッション ID と最終アクセス時刻 (ミリ秒単位) を格納するための動的マップが必要です。TreeMapこれは、アプリケーション スコープの Beanの内部として実装されます。アプリへの最初のアクセスごとに、現在のセッションがこの Bean の TreeMap に登録されます。このマップには限られた数のセッション エントリのみが許可され、超過したセッションは登録されません。また、新しいセッションを登録できるように、マップは古いセッション エントリから時々クリアされます。これが受け入れられるアプローチ/アプリケーション Bean の使用であるかどうかを知る必要があります。セッション エントリを一時的に外部 DB (ロータス ノート以外) に保存できることはわかっていますが、勤務先の会社では許可されていません。このアプローチにより、潜在的な問題が発生する可能性はありますか? はいの場合、これを行う別の方法はありますか?

4

2 に答える 2

5

これはアプリケーション Bean の完全に有効な使い方のように思えますが、2 つの提案をします。1 つ目は、TreeMap の代わりに ConcurrentSkipListMap を使用することです。前者はスレッドセーフですが、後者はそうではありません。下位のスコープとやり取りする場合、通常、スレッド セーフは重要ではありません。各ユーザーは自分のセッション、ビュー、およびリクエスト スコープにのみ書き込むことができますが、すべてのユーザーはアプリケーション スコープに書き込むことができるため、同時書き込みが発生する可能性があると考えられます。特にユーザーの負荷が高いアプリケーションでは。2 番目の提案は、アプリケーション Bean に格納される各セッションに関する情報の量に注意を促すことです。Bean にはすべてのユーザーがアクセスできるため、理論的には、あるユーザーに関する情報が多くなりすぎて、他のユーザーに誤って公開される可能性があります。もし、あんたが' 最終アクセス時間に加えてセッション名または ID のみを保存する場合は、問題ありません。しかし、実際に各ユーザーのセッション スコープへのポインターを格納している場合、他のユーザーがアクセスできないユーザーがキャッシュしたデータへのウィンドウを誤って提供してしまう可能性があります。これに噛まれる人を実際に見たことはありませんが、アプリケーション スコープにユーザー固有の情報を保存するときは、常にこのことを念頭に置いておくことが重要です。

于 2012-07-29T19:46:48.013 に答える
1

実際、これは Application Scope の有効な使い方です。それでも、TreeMapコレクションは状況に最適なアプローチではありません。これにはいくつかの問題があります。

  • 2 つの要求がコンテナー内のデータを変更する場合の同時実行の問題。
  • アプリケーションを水平方向にスケーリングする必要がある場合TreeMap、各マネージド Bean に 2 つの があります。

適切なアプローチは、キャ​​ッシュ システムを使用することです。これらの要件を満たす優れたキャッシュ ライブラリがあります。私はehcache をテストしました。アプリケーションをデプロイするノードが 2 つ以上ある場合に備えて、データとライブラリを処理するための同時管理を提供します。また、キャッシュをクリアするアルゴリズムを構成することもできます。 LRU (あまり使用されない) または FIFO (先入れ先出し) に基づいています。

外部データベースを使用してセッション ID を処理すると、データの取得/設定に時間がかかる場合があります (非常に短い場合もありますが、それでもディスク I/O 操作です)。その問題については、RAM に常駐する外部データベースとしてBigMemoryを使用するか、 BigTableのような NoSQL データベースを使用できます。

注: 私は ehcache で働いていませんし、商業的な方法で関連付けられているわけでもありません。テストしましたが、私のニーズを満たしています。JBoss Cacheのような他のキャッシュ システム ライブラリや、評価して使用できる他のキャッシュ システム ライブラリがあります。

于 2012-07-29T20:10:59.167 に答える