状態を維持する必要があるアプリがあるため、データを含むオブジェクト (大量の可能性があります) をクライアント (ブラウザー) が「会話型」の対話で問い合わせることができます。リクエストごとにデータをリロードするのは効率的ではありません。
Spring とセッション スコープの Bean を使用して、一部のセッション制御データを維持します。ただし、これらの新しい Bean は大きくなります。
これはセッション スコープ Bean の適切な使用でしょうか、それともキャッシュ (ehcache) の方が適切でしょうか?
本当に必要でない限り、キャッシング技術を導入することには消極的です。
もう 1 つの要因は、アプリをクラスターにデプロイする必要があることです。どの場合、アプリケーション サーバーのセッション レプリケーションによってセッション スコープ Bean がレプリケートされますか、または ehcache を使用する方が効率的でしょうか (クラスター内に分散できると思います)。
任意のガイダンスをいただければ幸いです。
Couple of thoughts on this (disclaimer: I work for terracotta/ehcache...so keep that in mind...but still trying to be unbiased here):
1 - Is there any redundant data in each of the sessions? Anything that could be shared across sessions? If yes, +1 for ehcache to store the shared stuff (because ehcache is optimized for heavy concurrency)
2 - How big are your session objects going to be? And how many concurrent users are you expecting on a steady state basis? (in other words, how much memory are you going to have to dedicate to session storage on your app server?)
If session footprint is not that big overall and can fit nicely in your heap without GC issues, then using session should be a fine solution.
But the bigger it gets, the larger your java heap will need to be...and the more you'll have to use voodoo tricks to keep garbage collections and gc pause times in check. By using ehcache, you can store centrally some objects that multiple sessions could access...hence consolidating your memory footprint (same point as 1) Additionally, by using the enterprise extension for ehcache (BigMemory=http://terracotta.org/products/bigmemory), you can bypass Heap limitations and store your data off-heap (as much as needed - 10s, 100s of GB or more). With that, the size of the objects that need to be in memory become irrelevant (as long as you can add RAM to your server of course)
3 - For session replication, app servers such as JBOSS, Weblogic, Websphere support it. Again, it's a matter of session size again (how much data will need to be replicated across the wire). If you session objects are big, and you have many of them, there will be a lot of network traffic across your cluster...could or could not work well. Having core objects in an distributed EhCache layer optimized for data storage, while keeping your session to a minimum (i.e. login / authentication information) would definitely enhance that session replication mechanism in my opinion.
Hope that helps.